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Forth Optimized eXpress*" 
The quick SC/FOX ran past the slow PC /BOX 
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USING THE HARRIS RTX 2000'™ RISC CPU 










Full-length PC, XT, AT, 386 Board 
10 to 50 Forth MIPS Operation 
8 MHz standard, 10 MHz upgrade 
64K standard, upgrade to IM byte 
All memory accessible by PC host 
Runs concurrently with PC host 
Includes Forth compiler system 






RTX 2000 Real Time Express"" CPU 
1-cycle 16x16=32 bit multiply, 
1-cycle 14 -priority interrupts, 
two 256-word stack memories, 
three 16-bit timer/ counters, 
8-channel 16-bit I/O bus 

Delivery: 2 weeks ARO 

Unit Price: $1,995 



Ideal for real-time control 



ction, miag( 
information 



SILICON COMPOSERS INC. 
210 California Ave. , Suite K, P^o Alto, CA 94306 (415) 322-8763 
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DESIGNING DATA STRUCTURES • MIKE ELOLA 
12 

Forth provides the basic foundation needed for object-oriented programming, by the ease with which new data 
structures can be defined. This series of articles will focus on the most portable of data objects, and on sharing 
operations between related objects. This installment educates the reader about basic concepts and ways to 
(•) evaluate objects and their operations. 
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OBJECT-ORIENTED FORTH • RICK HOSELTON 
15 

Any computer language can produce object-oriented programs, some just make it easier than others. Lan- 
guages like Smalltalk actually require an object approach. Forth can be extended easily to provide support for 
object programming; the author shares his own approach in code. 



STEP-TRACING IN fig-FORTH • GENE THOMAS 
20 

F83 has a DEBUG utility that single-steps through definitions at the touch of a key. fig-FORTH and its 
derivatives can now have a similar utility in their systems. The criteria for the solution boiled down to this: the 
application must not require any editing. Vectored execution to the rescue! 



LINEAR AUTOMATA • ANDREAS CARL 
23 

The idea for this program is from A.K. Dewdney, who wrote, "In a world of artificial computers, it is surpris- 
ing to imagine that we might be surrounded by a variety of natural computers like water, wind, or wood...." 
Cellular automata can demonstrate the arithmetic abilities of natural systems. Experimenting with this Forth 
program helps to make the point clear. 



VOLUME EIGHT INDEX • MIKE ELOLA 
26 

A comprehensive reference guide to all issues of Forth Dimensions published during the volume eight 
membership year. See the FIG Order Form to order complete sets of back issues. 



THE BEST OF GENIE • GARY SMITH 
29 

Sunday Q&A at the "Figgy Bar" is coming for Forth novices... And this column recaps some standards- 
making dialog fi-om the GEnie Forth RoundTable. Get a taste of what a proposer to the ANSI committee goes 
through to prepare his proposal. 
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Editorial 



harles Keane sent me a note on 
GEnie, to this effect: 

"At it's last meeting, the ANS Forth 
Technical Committee (X3J14) voted to 
constitute itself as a Speakers Bureau for 
FIG Chapters, specifically on the subject of 
current standardization activity. It also 
designated y'r ob't servant as the clearing- 
house for this effort. Interested chapters 
may contact me on GEnie (address 
C.KEANE), by phone (518-274-4774), or 
U.S. Mail (515 - 4th Avenue, Watervliet, 
NY 12189-3703)." 

Invite a scapegoat to dinner, anyone? 
Seriously though, folks, this sounds like a 
great way to get a good, close look into the 
horse's mouth (so to speak). I suspect that 
any speaker from X3I14 could relate 
enough about the ANS process and techni- 
cal tradeoffs to enUven and enlighten any 
meeting. 



We have been looking for material re- 
lated to object-oriented programming. 
There's a world fuU of people who think 
we'd be using objects, if we had any class. 
Mike Elola has kindly offered to bring 
objects to Ught in several articles. His first 
appears herein, and explains the fundamen- 
tal concepts and terminology of object- 
oriented programming. 

Like Forth, objects can be tough to 
appreciate without enough hands-on tink- 
ering to provide, at the least, a gestaltic 
moment or two. To that end. Rick Hoselton 
provides F83 code that supports object- 
oriented programming. (Other versions are 
also welcome, and Mike Elola will be 
developing one with that series of articles.) 
He offers another view of the general sub- 
ject, leaving it to the reader to develop some 
illustrations of the real usefulness of ob- 



jects. We continue to welcome well-chosen 
examples and stories about object-oriented 
programming in Forth. 

Any Forth programmer remotely inter- 
ested in this topic must read Dick 
Fountain's book, Object-Oriented Forth. 
It's mandatory — even the introduction is 
good. Add it to your library even if you're 
just generally interested in Forth tech- 
niques, especially ones involving data 
structures (Academic Press, 1987). 



I hope you can attend this year's Forth 
National Convention. Until this year, it 
always has been held in the vicinity of San 
Francisco. This was natural — most of its 
early organizers lived in that area, and the 
strong FIG chapters there supported it vig- 
orously as volunteer staff and as attendees, 
speakers, and exhibitors. Not incidentally, 
some local FIG members also attended the 
business group and board meetings at 
which the convention was planned. 

For years, there have be«n brief discus- 
sions about moving this keystone event of 
FIG's year to another locale. That would 
give local Forth programmers and vendors 
a chance to use the event as a showcase of 
their Forth-related work, and would pro- 
vide the local technical community with a 
chance to learn about contemporary Forth 
products and practices. Besides, the inevi- 
table infusion of techno-gossip and code- 
riddled repartee would give the local Forth 
community an infusion of ideas and a sense 
of perspective. But such discussions were 
usually short-lived, coming too late in the 
planning year and without local leadership 
or an actual plan. 

Martin Tracy lives in southern Califor- 
nia and is a member of the Board of Direc- 
(Continued on page 38.) 
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Letters 



ANS Process Offers Fairness 
Dear Marlin: 

This is in response to the letter from 
Gary Chanson (FD X/1) regarding an 
American National Standards Institute 
(ANSI) standard for Forth and the process 
which gets us there. 

I am NASA's representative on the 
ANSI Accredited Standards Committee 
(ASC) X3J14. 1 have attended every hour 
of every meeting of X3J14. 1 was as appre- 
hensive and suspicious before the first 
meeting as anybody had a right to be. My 
motivation was and is simple: I am a Forth 
user with important applications in view, 
and feel I have a stake in the outcome of the 
standards process. 

Gary's letter might have left some read- 
ers with the impression that this process has 
been commandeered by the big Forth ven- 
dors for their own purposes. Or that users 
have been left out. I would like to offer my 
testimony to the contrary. 

By my own observation I can attest that 
X3JI4 was formed in accordance with 
ANSI rules. It does, in fact, have an ANSI 
charter to draft a proposed ANSI standard. 
As far as I can tell, it is operating in scrupu- 
lous regard for the letter and the spirit of 
ANSI rules. 

Now, regarding ANSI rules, these are 
well-honed and rather inflexible. Space 
does not permit a full run-down on them 
here, but they are basically concerned with 
full public scrutiny; with guarantees that all 
input from any source be considered; and 
with ensuring that adequate time intervals 
are allowed for public response to proposed 
standards. These rules have resulted from 
decades of experience in developing stan- 
dards. They are designed to balance the 



numerous interests that are always in- 
volved, whether the field is nuts and bolts or 
computer languages. In my judgment, 
these rules prevent chaos: by adhering to 
them, a standard can come into being; and 
a standard, by definition, reduces chaos. 
Further, the rules seem to be about the only 
realistic approach to achieve fairness. 

Thus, even if they wanted to, or at- 
tempted to, the big Forth vendors probably 
would not have found it possible to com- 
mandeer the ANSI process. 

The other misimpression that might 
have been left by Gary's letter is really just 
the flip side of the above concern — that 
users have no voice. Actually, the represen- 
tation on X3J14 puts users in a near major- 
ity position. At my last count, there were 
nine producer members and 1 1 consumer 
members, with two others designated as 
"general interest." Membership, by the 
way (as has been stated widely and often), 
is completely open to anyone willing to pay 
the membership fee ($175), and who is 
willing to work, put in the time, and travel 
to the meetings. 

Certainly, none of us likes the idea of a 
new standard drafted in secret by a self- 
appointed clique and then handed down as 
though from on high. Gary's letter repre- 
sents the opinions of the Boston [chapter of 
the] Forth Interest Group, to the effect that 
they are ticked off by the past and don't 
want it repeated. My message is simple: 
take advantage of the new rules and the new 
process; get involved; make photocopies of 
the technical proposal and comment forms 
published in Forth Dimensions X/1 and in 
Dr. Dobb's Journal #131 (April 1988) and 
submit proposals and comments; seriously 
consider the possibility of becoming a 



member of X3J 14 to represent the points of 
view shared by you and your group. And be 
prepared in a year or so to get a copy of the 
draft proposed ANS Forth, study it, and 
comment on it formally. That, too, is part 
of the ANSI process. Your comments must 
receive due consideration and must be 
answered formally for the process to con- 
tinue. 

Perhaps the reaction expressed in 
Gary's letter stems from the way our exist- 
ing standard, Forth-83, was brought forth 
(or handed down?). That process, of 
course, was not the ANSI process. The 
rules were quite different. And with hind- 
sight we can see they were not adequate to 
prevent dissatisfaction. I understand all 
this, but that was five years ago, and five 
years is an eon in the world of computers. 
Grudges someday must be laid aside and 
realities be consulted. And we do have new 
realities staring us in the face (e.g., 32-bit 
microprocessors which were not real five 
years ago), and more realities to face 
shortly (e.g., optical storage). 

I believe that achieving ANS Forth will 
be an important event. It surely is inevi- 
table. X3J 14 is working very hard to make 
it a high quality achievement, one that will 
indeed have the broad support of users 
such as myself. But once again, your con- 
tributions are more than welcomed. They 
are expected! 

James L. Rash 
NASA 

Goddard Space Flight Center 
Greenbelt, Maryland 
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(Shattuck's screens.) 



Scr 


# 37 


KERNEL. BLK 







\ Task Dependant 


USER Variables 03Apr88cws 


1 


USER DEFINITIONS 








VARIABLE 


TOS 


\ 


TOP OF *5TArTC ) 


-J 


VARIABLE 


ENTRY 


( 


ENTRY POINT, CONTAINS MACHINE CODE ) 


A 


VARIABLE 


MPAGE 


( 


MEMORY PAGE ) 


5 




TTTMP 


{ 


ADDRESS OF RESTART OR NEXT TASK ) 


6 


VARIABLE 


LINK 


; 
I 


ijXIN is. iU rJ JCiA 1 i AO J\ ; 


7 


VARIABLE 


SPO 


{ 


INITIAL PARAMETER STACK ) 


Q 

8 


VARIABLE 


RPO 


( 


INITIAL RETURN STACK ) 


9 


VARIABLE 


DP 


( 


DICTIONARY POINTER ) 


10 


VARIABLE 


#OUT 


( 


NUMBER OF CHARACTERS EMITTED ) 


11 


VARIABLE 


#LINE 


( 


THE NUMBER OF LINES SENT SO FAR ) 


12 
13 
14 
15 


VARIABLE 


OFFSET 


( 


RELATIVE TO ABSOLUTE DISK BLOCK ) 



Scr # 22 CPU68000.BLK 

\ Multitasking low level 03Apr88cws 

1 LABEL (PAUSE) (S — ) 

2 IP SP -) MOVE RP SP -) MOVE ( push ip, rp ) 

3 UP bank L#) D7 MOVE D7 AO LMOVE ( load up ) 

4 SP AO ) MOVE ( sp to tos ) 8 AO LONG ADDQ WORD 

5 AO ) D7 MOVE D7 AO LMOVE ( point to next task) 

6 AO ) JMP C; ( jump to next task ) 

7 LABEL RESTART (S — ) 

8 SP )+ AO LMOVE ( pop return address, current link ) 

9 8 AO LONG SUBQ WORD AO UP bank L#) MOVE ( get up ) 

10 AO ) D7 MOVE D7 SP LMOVE ( restore stack ) 

11 SP )+ D7 MOVE D7 RP LMOVE ( restore rp ) 

12 SP )+ D7 MOVE D7 IP LMOVE ( restore ip ) 

1 3 NEXT C ; 

14 ENTRY LINK I ( I point to myself ) 
15 



Scr 


# 23 


CPU68000 .BLK 





\ Manipulate Tasks 


04Apr88cws 


1 


HEX 






2 


4EF9 CONSTANT JMPL# \ 


op word for a long jump 


3 


4EB9 CONSTANT JSRL# \ 


op word for a long jump to subroutine 


4 


DECIMAL 






5 


: LOCAL 


(S base addr 


-- addr' ) UP ® - + ; 


6 


: ©LINK 


(S -- addr ) 


LINK @ ; 


7 


: !LINK 


(S addr -- ) 


LINK ! ; 


8 


: SLEEP 


(S addr — ) 


DUP LINK LOCAL ® OVER JUMP LOCAL ! 


9 






JMPL# SWAP ENTRY LOCAL ! ; 


10 


: WAKE 


(S addr -- ) 


RESTART OVER JUMP LOCAL ! 


11 






JSRL# SWAP ENTRY LOCAL ! ; 


12 


: STOP 


(S — ) UP 


@ SLEEP PAUSE 


13 


: SINGLE 


(S — ) [ ' 


] PAUSE >BODY ['] PAUSE ! ; 


14 


: MULTI 


(S -- ) UP 


@ WAKE (PAUSE) ['] PAUSE ! ; 


15 
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(McBrien's screens.) 



: r e e n c 1 U 

1 ( DISFORTHer primitives. Retyped by Chris McBrien 20 Sept 1987. 

2 Adapted from Hewlett Packard's 9835 FORTH User's Manual. 

.i 

4 DISFORTH will decompile a Forth word into it's component 

5 words or tell you if it is a USER, VARIABLE or CODE 

6 d e f i n i t i o n . To ease typing, DISFORTH i s r e n a m e d SEE ) 



8 1 

9 2 
1 4 
1 1 5 
1 2 

1 3 : 
1 4 
1 5 
1 6 

ok 

Scree 



VARIABLE STRINGLIST ] ( . " ) [ 

VARIABLE TERMINATORS ] ;S (;CODE) [ 

VARIABLE BRANCHES ] (LOOP) (+LOOP) BRANCH OBRANCH [ 

VARIABLE LITERALIST ] LIT (LOOP) (+LOOP) BRANCH OBRANCH [ 



ELEMENT? ( n \ list ELEMENT? pos) ( list 
DUP 2+ SWAP @ 2 ♦ OVER + SWAP 

DO I @ OVER = IF DROP I LEAVE THEN 2 +LOOP 
IF THEN ; 



searched for n ) 



-> 



1 ( 



6 
7 
8 
9 
10 
1 1 
1 2 
1 3 
1 4 
15 
1 6 
ok 



n 2 11 
DISF 
PRIN 
CR D 
DUP 
SPAC 
DUP 



DUP 
DUP 



ORTHe r 
T-WORD 
UP U. 

@ DUP U. SPACE 
E DUP 2+ NFA ID. 
STRINGLIST ELEMENT? IF 
SWAP 2+ COUNT 2 DUP TYPE 
+ 2 - SWAP THEN 

' COMPILE CFA = IF SWAP 2+ DUP @ 
LITERALIST ELEMENT? IF 
SWAP 2+ DUP @ ROT BRANCHE 
ELSE DROP THEN 2+ ; 



( pfaddr PRINT-WORD next addr ) 

a d d r e 
cfa ) 
n a rn e 
if in 
t h e n 



NF/ 



Pag. 

:.s ) 



2 of 3 ) 



A ID. 
ELEMENT? IF OVER 



) 

line s 
type i 

SWAP T 

+ THE 



t r i n q ) 
t o u t ) 

HEN 

N U . 



P R I N T - D E F 
BEGIN DUP e 
PRINT 



( PFA PRINT-DEF ) 
TERMINATORS ELEMENT? 0= WHILE 
-WORD REPEAT PRINT-WORD DROP ; 



--> 



No TRAPS in 
His Multitasker... 

Dear Marlin, 

I want to thank you very much for pub- 
lishing the article by Robert J. Eager, 
"Relocatable F83 for the 68000" {FD IX/ 
6). I know that some people don't want to 
see such machine-specific articles in 
Forth Dimensions, but this one really 
helped me. I have a copy of F83 modified 
for the Atari ST by George Morison. Mr. 
Morison did a wonderful job of porting 
F83 to the Atari, with the same basic idea 
used by Mr. Eager. Unfortunately, both 
the single-step debugger and the multi- 
tasker caused the system to bomb, so I did 
without them. With the help of Mr. 
Eager's article, I was able to fix the debug- 
ger almost immediately, and used it to 
tackle the multitasker. 

After hours of constant bombing, I de- 



cided there must be something about 68000 
traps that I just didn't understand. It oc- 
curred to me that I could add another couple 
of bytes to the user area to allow the use of 
the JSR instruction rather than the TRAP 
instruction. This means a Uttle more com- 
plexity for the words wake and s lee p , but 
the code works, is easy to understand, and 
avoids some extra stack popping required 
by the trap instruction, so it may even run 
faster, wake now puts a jsrl instruction 
into ENTRY and the address of restart 
into a new user variable called JUMP. 
SLEEP puts a JMPL instruction into en- 
try and the address of the next task (taken 
from LINK) into JUMP. The included code 
is specific to the 68(XX) but I imagine the 
same idea would work with any processor, 
but without requiring any knowledge of 
traps and exception vectors. 

Let's continue to hear more about multi- 



tasking in Forth Dimensions, and how 
about some articles about implementing 
multi-user Forth as well? 

Sincerely, 
Charley Shattuck 
1509 Gerry Way 
RoseviUe, CA 95661 

Visible Forth 
(with no exceptions) 

Dear Editor, 

With reference to Rich Franzen ' s "The 
Visible Forth" (FD IX/3), the EXCEP- 
TIONS in screen 17 do seem to make the 
application rather non-portable, at least 
until the user has sorted out the addresses 
of the exception words. 

Although I claim no originality for the 
application submitted, I have cleaned it up 
and gotten rid of one major typing error. 
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Screen 212 

1 ( DISFORTHer . . . Page 3 of 3 ) 



2 • 


DI SFORTH 


( DISFORTH cccc eg: DISFORTH VLIST 


) 


3 


CLS 


( Clear the screen 


) 


4 


CR [COMPILE] ' DUP NFA ID. ( get PFA of cccc 


3 


5 


DUP NFA C0 64 AND IF ." ...is an IMMEDIATE word" THEN 




6 


DUP CFA @ 


[ ' . CFA @ ] LITERAL = IF ( colon definition 


) 


7 
8 


PRINT 
ELSE DUP 


-DEF 

CFA @ [ ' FENCE CFA @ ] LITERAL = IF 




s 


li 


..is a USER variable. OFFSET = " @ . CR 




1 


ELSE DUP 


CFA @ [ ' CFA @ ] LITERAL = IF 




1 1 




..is a CONSTANT. VALUE = " @ . CR 




1 2 


ELSE DUP 


CFA @ [ ' USER CFA (? ] LITERAL = IF 




1 3 




..is a VARIABLE. CONTENTS = " @ . CR 




1 4 


ELSE . " . 


..is a CODE definition. " C R 




15 


DROP 


THEN THEN THEN THEN CR ; 




1 & 
ok 


SEE BASE @ >R HEX DISFORTH R> BASE ! ; ( SEE VLIST 


) 



Screen 231 

1 ( TRIAL... To test the resolving of a BRANCH ) 

■-1 
C 

3 : TRIAL 10 DO CR ." BRANCH TEST" 

4 LOOP CR ; 
5 

6 

7 

8 

'3 
10 
1 1 
1 2 
1 3 
1 4 
1 5 
1 6 
ok 



TRIAL 






58DB 


405 


LIT A 


5 8 D F 


8CB 





58E1 


584 


(DO) 


5 8E3 


2025 


CR 


58E6 


A68 


(.") BRANCH 


5 8F3 


553 


(LOOP) BIDS 


58F7 


2025 


CR 


5 8FS 


596 


;s 


ok 







58D0 


05 


85 


54 


52 


49 


41 


CC 


B7 


5 8 


OA 


07 


D5 


04 


OA 


00 


CB 


. .TRIAL7X . .U. . .K 


5 8 E 


08 


84 


05 


25 


2 


68 


OA 


OB 


42 


52 


41 


4E 


43 


48 


20 


54 


. . .% h . . BRANCH T 


5 8F0 


45 


53 


54 


53 


05 


E3 


5 8 


2 5 


2 


9 6 


05 


04 


44 


55 


4D 


5 


ESTS . cX% ... DUMP 


5900 


2 


2 


20 


20 


20 


20 


2 


2 


2 


20 


20 


20 


20 


2 


20 


20 




59 10 
ok 


20 


20 


20 


20 


20 


20 


2 


2 


20 


20 


20 


2 


2 


OB 


59 


2 5 


. Y% 



Forth Dimensions 



8 



Volume X, Number 2 



(McBrien' s screens, continued.) 



Screen Z 

1 ( E L E M E N T V Decompile hi g h level F o r t. h d e f i n i t i o n s 



3 1 VARIABLE S T R I N G L I S T 

4 2 VARIABLE TERMINATOR'^ 

5 VARIABLE BRANCHES 

6 5 VARIABLE LITERALIST 



] (•") [ 

] ;S (;CODE) [ 

] [ 

] LIT (LOOP) (+LOOP) BRANCH OBRANCH [ 



8 ( The c f a of a word along with it 



relevant list ' ELEMENT? ' 



9 
1 
1 1 
1 2 
1 3 
1 4 
1 5 
1 6 
ok 



S c r e < 
1 



4 
5 
6 
7 
8 
9 
10 
1 1 
1 2 
1 3 
1 4 
15 
1 6 
ok 



gives the address of the c f a in that list ) 

ELEMENT? ( cfa \ list addr in the list ) 

element? 71 EE 



. i n rn y s y s t e rn ) 



( 5 9 3 B R A N C H E 'i 
DUP 2+ SWAP @ 2 ♦ OVER + SWAP 

DO I @ OVER = IF DROP I LEAVE THEN 2 +LOOP 
IF THEN : 



, 201 
PRIN 
PRIN 
CR D 
DUP 
SPAC 
DUP 



T-WORD 
T-WORD 
U P U . 
@ DUP U. 
E DUP 2+ 
STRINGL I ST 
IF SWAP 2+ 
THEN DUP ' 



M o r e 
( pta 



c o m p i 1 i n q w o 
next p f a ) 



r ds 



SPACE 
N FA ID. 

ELEMENT? 
COUNT 2DUP TYPE 
COMPILE CFA = 



p r i n t 

p r i n t 

p r i n t 
i f 



a n 



+ 



IF SWAP ; 
THEN DUP 
I F 



+ DUP @ 2+ 
L ITERAL I ST 



:.WAP 



5WAP 



t h e 
t he 
the 
i n 1 

( t 



p f a 
cfa 
n a rn e 
i n e s 
ype i 



t r i n g ) 
t o u t ■) 



SWAP 2+ 
IF OVER 
THEN U. 
ELSE DROP 
THEN 2+ ; 



DUP 
+ 



NFA ID 
ELEMENT? 
@ ROT BRANCHES 



ELEMENT' 



Listing One is the original, semi-working 
version but, as can be seen, the branch 
resolving is not correct according to the test 
word TRIAL. (Joke SEA TRIALS.) I am a 
novice Forth programmer and have been 
unable to cure this branching problem apart 
from the vicious hack in Listing Two, in 
which I removed the words from 
VARIABLE BRANCHES simply because 
the branch address seemed to be double 
what it should be; so I removed the dupU- 
caie branch words, and it worked. The test 
word AA in Listing Two is resolved cor- 
rectly. If anyone can throw some Ught on 
this slight problem, I — for one — would 
learn a little more. Also, I feel this version 



would be more portable than Rich's: it 
originally came from a Hewlett-Packard 
9835 application later modified for an HP 
86, which uses an octal-based processor. 

My system is basically a Forth-79 ker- 
nel, with additional words for an MS-DOS 
system running on a Hewlett-Packard 150. 
(Notice that screens' line numbers go from 
one through 16, not zero through 15. This 
does mean that .line is one off when 
used. Why don ' t people stick to a standard? 

Chris McBrien 
1. Milton of Straloch 
Newmachar, 
Aberdeen, Scotland 



Errata and Improvements 
to a 6502 Assembler 
Dear Marlin, 

While using the assembler I described 
in Forth Dimensions (IX/5), 1 have discov- 
ered several bugs. The first of these was 
due to my ignorance of some opcode proce- 
dures; the others were just errors. 

There are a number of operations, such 
as LDA, for which the lists of available 
addressing modes include: 

Absolute, X 

Absolute, Y 

Zero page, X 
but not Zero page, Y. 
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I hadn't realized that the missing Zero 
page, Y addressing mode could be in- 
voked by using an absolute address refer- 
ence to zero page (e.g., OOEl). In trying to 
modify the assembler to automatically 
compile an absolute zero-page address 
when appropriate, I found a few more 
bugs. So I decided to simplify the logic 
sequence and correct the screens. Screens 
2, 3, 5, 8, and 9 have small changes; 
screens 4 and 6 have massive changes 
based on use of the new words ? legal, 
?ZP,and ?IMM. 

The suggested improvement is the use 
of equates. One of the conveniences of a 
conventional assembler is the provision 
for using names for addresses; e.g.: 
COUT EQU $FDED 
TEMP EQU $E1 

In the Forth assembler, COUT and 
TEMP can be defined as constants, but are 
needed only temporarily. If such con- 
stants are defined (either before or after 
the assembler is loaded) after space has 
been allotted for the assembler and before 
the dictionary pointer has been reset to the 
top of the core vocabulary, they will be 
available to the assembler but will be 
forgotten along with it when the vocabu- 
lary linkage is changed after assembly is 
complete. 

Sincerely, 
Chester H. Page 
1707 Merrifields Drive 
Silver Spring, Maryland 



ASSEMBLER SCR » 1 






\ 


Assembl y samp 1 e 


1 


\ 


Conventional formait 


2 


\ 


LDA *tO 


3 


\ 


LDY »*80 


4 


\ 


LI STA 300, Y 


5 


\ 


DEY 


6 


\ 


BPL LI 


7 


\ 


JMP NEXT 


8 






9 


\ 


Format +or this assembler 


10 


\ 


ASSEMBLE TEST 


1 1 


\ 


« LDA, 80 « LDY, 101 300 


12 


\ 


END 


13 






14 




-> 


15 
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,Y STA, DEY, 101 BPL, GONEXT 



ASSEMBLER SCR 

1 
2 
3 
4 
5 
6 
7 
8 
9 



tt 2 



08MAR88CHP 



\ 

HEX 

UOCABULARY ASSEMBLER 
ASSEMBLER DEFINITIONS 
VARIABLE MODE 
VARIABLE MODE. KEY 

\ The allowable numbers of labels and references is controlled 
\ in the rest of this screen 

14 ARRAY LABEL. TABLE \ Provide for 20 labels, and 

CREATE REF. TABLE , , 56 ALLOT \ for 30 references 

10 VARIABLE REF. POINTER 

11 ! CLEAR. TABLES 15 1 DO I LABEL. TABLE I 

12 REF. TABLE 3 + REF. POINTER ! ; 

13 VARIABLE L0N6.ADDR 

14 — > 
15 
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LOOP 
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Modes 
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1 




2P 





MODE ! 


MODE. KEY ! ; 


\ 


Adds 


4 to 


opcode 


2 






\ 


ZP i s 


def au 1 t mode 










3 




,X 


1 


MODE 1 


1 MODE. KEY 1 ; 


\ 


Adds 


14 


(zero page ,X> 


4 




,Y 


2 


MODE ! 


202 MODE. KEY ! ; 


\ 


Adds 


14 - 


LDX , STX , on 1 y 


5 




X) 


3 


MODE \ 


4 MODE. KEY ! j 


\ 


Adds 





(ZP.X) 


6 




)Y 


4 


MODE ! 


8 MODE. KEY 1 ; 


\ 


Adds 


10 


( Z P ) , Y 


^ 




# 


5 


MODE ! 


110 MODE. KEY 1 ; 


\ 


Adds 


8 


Immed i ate 


8 




.A 


6 


MODE 1 


20 MODE. KEY ! ; 


\ 


Adds 


3 


Accumu 1 a tor 


9 




) 


7 


MODE ! 


40 MODE. KEY 1 ; 


\ 


Adds 


2C - 


Indirect JMPs only 


10 






8 








Adds 


C - 


Absolute address 


1 1 






9 








Adds 


IC - 


Abs-ol ute ,X 


12 


\ 




A 








Adds 


18 - 


Absol ute , Y 


13 


CREATE 


ADD. TABLE \ Indexed 


by 


mode 


u a 1 u e 


14 




1404 


, 0014 


, 0810 , 2C08 , 


ICO 


C , 18 C, 




15 




-> 

















ASSEMBLER SCR « 4 

\ A IS a given address 09MAR88CHP 

1 \ C is address returned by opcode mnemonic 

2 : ?LEeAL i C C) DUP 1+ CS) MODE. KEY lil AND FF AND 

3 ABORT" Illegal Opcode" DUP C3 20 = \ Check for ,A 

4 0= IF OVER 100 U< 0= IF MODE. KEY 3 OC AND 

5 ABORT" Illegal Indirect" THEN THEN ! 

7 : ABS.ADDR DUP 1+ 3 MODE . KEY 3 DUP 3C AND 

8 ABORT" Illegal address" DUP 40 = IF DROP DROP ELSE AND 200 = 

9 IF -1 MODE +! THEN 8 MODE +! THEN 1 LONG.ADDR ! j 

10 : ?ZP ( C C) MODE. KEY 3 20 = 0= IF OVER 100 U< 0= 

11 OVER 1+ C3 MODE. KEY 3 OVER OR 262 = SWAP 3F = OR OR 

12 IF ABS.ADDR THEN THEN ; 
13 

14 ! ?IMM DUP 1+ 3 MODE. KEY 3 AND 100 = IF -2 MODE +! THEN ; — > 

15 \ Special treatment of immediate with CPX , CPY , STX, or STY, 
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ASSEMBLER SCR « 5 

\ 

1 ! LABEL. SAIJE FF AND DUP LABEL. TABLE 3 
ABORT" Duplicate label" 
HERE SWAP LABEL. TABLE I ; 



2 
3 
4 
5 
6 
7 
8 
9 
10 
1 1 
12 
13 
14 
15 



09MAR88CHP 
\ Not new 1 abe 1 ? 

\ Save label address 



LCI SP3 SO 4 
LC2 SP3 SO 6 



= IF SWAP LABEL. SAUE THEN 
= IF ROT LABEL. SAWE THEN 



COMPILE. ADDRESS < A ) 

DUP FFOO AND 100 = \ Is it a label? 

IF HERE REF. POINTER 3 OVER C! \ Full address label needed 
1+ ! \ Save compilation address 

3 REF. POINTER +1 \ Advance -for next entry 

THEN LONG.ADDR 3 

IF , ELSE C, THEN ; \ Compile absolute address or ZP byte 

— > 



09MAR88CHP 



ASSEMBLER SCR « 6 

\ CREATE operators -for de-fining mnemonics 

1 \ Multimode opcodes 

2 : M/CPU CREATE 2 ALLOT C, , DOES> LONG.ADDR I LC2 ?LEGAL 

3 ?ZP ?IMM 

4 C3 MODE C3 ADD. TABLE + C3 + C , \ Adjust opcode 

5 MODE. KEY 3 20 = 0= IF COMPI LE .ADDRESS THEN ZP ; 

6 

7 \ Single-mode opcodes 

8 : CPU CREATE 2 ALLOT C, DOES> LCI C3 C , ZP ; 
9 

10 : BRANCHES CREATE 2 ALLOT C, DOES> LC2 

11 C3 C, C, 

12 HERE 1- REF. POINTER 3 1 OVER C! \ Branch o-f-fset needed 

13 1+ I \ Save compilation address 

14 3 REF. POINTER +! ZP ; \ Advance -for next entry 

15 — > 



ASSEMBLER SCR « 7 

\ Second pass replaces stored label targets 21JUL87CHP 

1 : SECOND. PASS 

2 BEGIN -3 REF. POINTER +1 REF. POINTER 3 DUP 1+ 3 

3 \ Find label compilation address 

4 DUP WHILE DUP C3 DUP LABEL. TABLE 3 \ Label address 

5 3 ROLL C3 \ Word-or-byte ^lag 

6 IF 2 PICK - 1- \ O-f-fset 

7 DUP ABS 7F > 

3 IF DROP CR ." Branch to " 100 * . ." is too -far" 

9 ." <or label is missing)" SPI QUIT 

10 THEN ROT C! 

11 ELSE ROT ! 

12 THEN DROP REPEAT DROP DROP j 
13 

14 — • 

15 
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\ Definitions o-f mnemon 
0060 61 M/CPU ADC, 0060 
0060 41 M/CPU EOR, 
0060 81 M/CPU STA, 
025E 02 M/CPU ASL , 
025E 22 M/CPU ROL , 
027E C2 M/CPU DEC, 
016F EO M/CPU CPX, 

8 036D A2 M/CPU LDX , 

9 007E 80 M/CPU STY, 

10 00 CPU BRK, 18 CPU CLC, 

1 1 CA CPU DEX , 88 CPU DEY , 

12 48 CPU PHA, 

13 60 CPU RTS, 

14 A8 CPU TAY, 



0060 
0060 
025E 
025E 
027E 
016F 
016E 
007F 



ROR, 
INC, 



08 CPU PHP, 
38 CPU SEC, 
BA CPU TSX, 



I ce 

21 M/CPU AND 
01 M/CPU ORA 
Al M/CPU LDA 
42 M/CPU LSR 
62 M/CPU 
E2 M/CPU 
CO M/CPU CRY 
AO M/CPU LDY 
20 M/CPU BIT 
D8 CPU CLD, 
E8 CPU I NX, 
68 CPU PLA, 
F8 CPU SED, 
3A CPU TXA, 



08MAR88CHP 
0060 CI M/CPU CMP, 
0060 El M/CPU SBC, 



027D 
003F 
58 CPU 
C8 CPU 
28 CPU 
78 CPU 
9A CPU 



82 M/CPU STX, 
40 M/CPU JMP, 
CH , Be CPU CLV, 



INY, 
PLP, 
SEI , 
TXS, 



EA CPU NOP, 
40 CPU RTI , 
AA CPU TAX, 
93 CPU TYA, 



15 



{Letters screens continued on page 22.) 




NGS FORTH 

A FAST FORTH, 
OPTIMIZED FOR THE IBM 
PERSONAL COMPUTER AND 
MS-DOS COMPATIBLES. 



STANDARD FEATURES 
IMCLUDE: 

•79 STANEARD 

•DIRECT I/O ACCESS 

•FULL ACCESS TO MS-DOS 
FILES AND FUNCTIONS 

•ENVIRONMENT SAVE 
& LOAD 

•MULTI-SEGMENTED FOR 
LARGE APPLICATIONS 

•EXTENDED ADDRESSING 

•MEMORY ALLOCATION 
CONFIGURABLE ON-LINE 

•AUTO LOAD SCREEN BOOT 

•LINE & SCREEN EDITORS 

•DECOMPILER AND 

DEBUGGING AIDS 

•8088 ASSEMBLER 
•GRAPHICS & SOUND 
•NGS ENHANCEMENTS 
•DETAILED MANUAL 
•INEXPENSIVE UPGRADES 
•NGS USER NEWSLETTER 

A COMPLETE FORTH 
DEVELOI^iENT SYSTEM. 



PRICES START AT $70 



NEW^HP-150 « HP-110 
VERSIONS AVAILABLE 



1^ 



NEXT GENERATION SYSTEMS 
P.O.BOX 2987 
SANTA CLARA, CA. 95055 
(408) 241-5909 
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DESIGNING 

DATA STRUCTURES 

MIKE ELOLA - SAN JOSE, CAUFORNIA 



A orth includes all the fundamental 
tools needed to create data objects. With 
these tools, you can create innumerable 
different kinds of such objects. 

For this series of articles, our focus will 
be on the data objects that are most port- 
able across CPUs of different bit widths, 
and on the ability to share operations be- 
tween related types of objects. Without 
these concerns for portability and pooling 
of operations, designing new data objects 
has been guided by two main criteria: the 
simplicity with which frequently associ- 
ated operations can be implemented 
(which also affects the speediness of such 
operations) and the memory compactness 
of the layout (which often inversely affects 
the simplicity of the associated opera- 
tions). 

New designs should be evaluated with 
respect to all these criteria. In this discus- 
sion, the performance and compacmess of 
the code will only be mentioned when new 
design approaches threaten to compromise 
them too much. 

The many topics about data objects 
include: how much data typing is sup- 
ported by Forth; what constitues a Forth 
data type; how portability issues converge 
with data typing issues; and how data typ- 
ing can be implemented. Another topic 
which is often treated too lightly is the 
choice of action (specified following 
DOE S >) in user-suppUed, data-declaration 
routines. This action is adopted by all data 
objects created with the parent declarator. 
Throughout this text, I will refer to this 
behavior as the "default" or "initial" opera- 
tion. 

The Quest for Reliable Object Designs 
To be able to talk about goals such as 



"reUability," several basic terms must be 
understood precisely. 

Objects are binary representations of 
numbers, dates, letters, or other abstrac- 
tions. The individual bits that comprise the 
object are usually grouped into larger units, 
which can represent more than a Boolean 
on/off state. These bit-groupings help to 
structure the object. 

'^An object is sim- 
ply a collection of 
properties/' 

The design of objects encompasses 
more than structure alone. Each structural 
component of an object is invested with a 
particular interpretation, which gives rise 
to the properties exhibited by the object An 
object can be thought of as a collection of 
structural components and their associated 
interpretations. A more portable, or im- 
plementation-independent, way to view an 
object is simply as a collection of proper- 
ties. For example, a signed integer has a 
sign property. The sign property arises 
from a particular component of the object, 
such as the interpretation of the most sig- 
nificant bit. 

Identifying each context in which the 
object is intended to be used will help to 
determine the properties of the object. For 
example, assume you have to store phone 
numbers. While a sign bit would not serve 
any useful purpose in this context, a "work" 
or "home" discriminator might be useful. A 
32-bit signed integer object could still be 
used for storing the numbers, but the object 
would not have a sign property. Instead, the 



bit normally associated with a sign could 
be interpreted as a work/home flag, an al- 
together different property. 

Operations act upon an object by tak- 
ing advantage of known properties of the 
object. For example, a multiply operation 
uses the sign bits of its operands to deter- 
mine the sign bit of the result. This way, 
the properties of the result are consistent 
with the properties of the input objects. 

If we know the properties of the resul- 
tant object, we may say that the object is 
reliable with respect to the operation. 
When the result is an object with un- 
known properties, the operation is unreli- 
able with respect to the object. For ex- 
ample, a string concatenation operation is 
reliable when it properly accounts for the 
maximum-length property of the string 
into which the result is stored. By design- 
ing operations which respect the invariant 
properties of objects, we make our data 
objects "reliable." (See Reliable Data 
Structures in C by Thomas Phim for a 
more detailed discussion of this subject.) 

The process of object design requires 
careful judgments about all the properties 
and operations an object should support. 
These properties and operations cannot 
be considered separately. The necessity 
for specific operations determines the 
choice of properties for an object. Like- 
wise, the choice of properties impacts the 
operations that can be reliably performed 
upon an object. A string storage operator 
cannot reliably store a string unless the 
string variable includes a "maximum 
length" property, so that it can at least 
report error conditions arising from space 
limitations. So the design of objects alter- 
nates between consideration of the opera- 
tions to be supported and consideration of 
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the structural components that reliably 
support those properties. 

Forth Data Types 

Forth is a typed language, in terms of 
having many objects that share the same 
properties. Accordingly, operators and 
objects must be correctly paired. For ex- 
ample, the EMIT operation is only useful 
when applied to the correct object The 
Forth programmer must oversee the proper 
matchup between operations and objects. 
Other languages also expect you to make 
the proper matchups, but they can provide 
a warning when you have made a mistake. 
Forth provides no such warning, unless you 
add the necessary code to make this pos- 
sible. But Forth's lack of built-in type 
checking does not imply an absence of data 
types or any special dislike of data types. 

The topic of Forth data types is often a 
sensitive one. Most authorities would say 
that the absence of strongly enforced data 
typing is bad. What they are really saying is 
that most programmers cannot keep track 
as well as the computer can of what they 
declare, and this is inarguably true. But by 
overcompensating for human frailty with 
strictly enforced type checking, languages 
become too confining. 

Few languages besides Forth will let 
you make the final decision about whether 
an operator and an operand will be suitable 
for one another. So sets of operations 
(COUNT, -TRAILING, and TYPE for ex- 
ample) can be intermixed in ways that 
support a variety of objects, and with much 
greater efficiency in Forth than in most 
other languages. 

Properties of 
Forth Data Objects 

The prc^rties of an object arise out of 
the unambiguous and stable interpretations 
we associate with each bit and byte of an 
object. Properties also include other facts 
about an object, such as a length (including 
component parts) and the layout The lay- 
outproperties of a multi-part object involve 
the order of the parts and their offsets from 
the start of the object. 

These shared properties of data objects 
give rise to data types like integer variables, 
ASCII character codes, arrays, etc. As a 
designer, you need little more than consis- 
tency among a group of objects to establish 
data types. (Because it encapsulates a 
group of properties, even one instance of an 



object establishes a data type.) 

"Variable" is a convenient label for a 
group of similar objects. The word variable 
is used to identify a type of object without 
redescribing it The term helps to displace 
phrases like "16-bit, signed integer value." 
("Variable"refers to the variable data type 
— the group of objects with the properties 
we commonly associate with Forth 
variables, variable refers to the Forth 
routine that creates instances of variables.) 

In Forth, named data objects have a 
parent code field address (CFA) associated 
with them. Although the CFA (and 
associated doe S > phrase) is more a behav- 
ioral inheritance of the data object, that 
behavior is tighdy bound to the object. As 
such, this behavior can be loosely consid- 
ered a property of the object. If you think of 
the CFA as a physical subcomponent of the 
object, this idea gains more respectability. 

The behavior of a constant is to return 
the value with which it was declared. That 
action can be considered an operation, 
rather than a property. Here's why: to de- 
sign the initial operation for a constant, first 
you must take into account the width of the 
stored datum, so that the correct fetch op- 
erator can be engaged. Therefore, the width 
of the object is the fundamental property. 

A data object need not have any opera- 
tional property, as in the case of user vari- 
ables. Memory has been allocated for user 
variables without a nearby CFA and label. 
Other examples of objects without built-in 
operational properties are disk buffers and 
headerless tables. 

Reusability of Operations 

Provisions for data typing block the 
compilation of an incorrect type of operator 
for an object, or else report a fatal error at 
run time. (Some compilers will perform 
type conversions automatically to avoid 
Uiis error, but that digresses...) In object- 
oriented languages, provisions for objects 
assist in the selection of the correct type of 
operation through hierarchical data typing; 
if the current operation type is not found, an 
appropriate parent type operation may be 
selected. This operator-selection mecha- 
nism is called inheritance. 

Careful design of Forth data objects also 
allows operations to be reused by different 
objects. The reusability of operations has 
received recent attention due to its intro- 
duction in object-oriented versions of es- 
tabhshed languages. In Forth, however, this 



kind of inheritance mechanism is overkill. 
When objects inherit operations, they are 
"enabled" for use. Without data abstraction 
or data type enforcement. Forth operations 
are always enabled for use with any object; 
but the selection mechanism is that crea- 
ture known as the programmer. 

Objects which have identical properties 
can be directly manipulated by a common 
set of operations. Objects may also be de- 
signed that share certain properties and not 
others. In such cases, you can often use a 
subset of the operations for both types of 
objects — particularly, the operations 
which engage only the property or proper- 
ties shared by the different objects. 

For example, an array of characters can 
be one object printed by type, and a 
counted-string is another object that can be 
printed by type when preceded by 
COUNT . You could also say thatTYPE only 
works on one object (an array of charac- 
ters), and it is incidental that the object may 
be part of another object. Whatever view 
you take, an array of characters is the prop- 
erty shared by both these objects, and at 
least that much can be clearly stated. 

For this discussion, I will not consider 
parts of objects to be distinct objects. 
Rather, I encourage the reader to think of 
such a subcomponent as a distinct prop- 
erty. Any such properties can be shared by 
one or more different objects. In other 
words, treat the properties of an object as 
traits that must be individually accounted 
for by the applicable operations. Because 
TYPE only addresses the property of an 
array of characters, it can be applied to a 
variety of objects with that component 
property. (A side-effect of making opera- 
tions property oriented rather than object 
oriented is that strict data type enforcement 
becomes more difficult.) 

By designing objects to share important 
properties, we will also be able to design 
reusable operations for those objects. So a 
design strategy for data objects and their 
supporting operations may be: 

When designing data objects that are 
closely related to one another, choose 
layouts that are as regular (standard) as 
possible, which results in shared layout 
properties. Similarly, choose the initial 
operations so that their functionality 
dovetails with pre-existing operations. 
(Efficiencies are more likely to be real- 
ized when objects have as many shared 
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For Programming Professionals: 

an expanding family of 
compatible, high-performance, 
Forth-83 Standard compilers 
for microcomputers 

For Development: 

Interactive Forth-83 Interpreter/Compilers 

• 16-bit and 32-bit implementations 

• Full screen editor and assembler 

• Uses standard operating system files 

• 400 page manual written in plain English 

• Options include software floating point, arittimetic 
coprocessor support, symbolic debugger, native code 
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• Unique table-driven multi-pass Fortfi compiler 
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• Technical Assistance Hotline 

• Periodic newsletters and low-cost updates 

• Bulletin Board System 
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properties as possible.) 

Such a strategy should yield a robust sub- 
set of general operations, as well as a 
minimal subset of object-specific opera- 
tions. 

Categorizing Operations 

There are a couple of ways to catego- 
rize operations: as memory based or stack 
based. Since strings cannot be placed on 
the stack, string operations are memory 
based (although parameters for such string 
operations may be passed on the stack). 

Later, we will categorize operations as 
object sensitive (or object specific) and 
object insensitive. An object-insensitive 
operation could be applied to many dis- 
tinct, but related objects, type was 
shown to be an object-insensitive opera- 
tion which can be used across different 
string objects. 

Tiers of Operations 

A user variable is structured differ- 
enUy than a variable or a constant. The 
initial operation of a user variable fetches 
an address that points to the associated 
value. The net effect is the same as with a 
variable (yielding the address of a cell). 
However, a different initial operation was 
required, in order to account for the differ- 
ent layout property of a user variable: a 
pointer resides where the value would 
normally be. Once the address is placed on 
the stack, the fetch and store operators (@ 
and!) can be used with either type of 
variable. So those operators are object- 
insensitive, because they can be used with 
several types of objects. 

To be precise, these different kinds 
objects ultimately make reference to a cell 
and, therefore, exhibit cell properties. The 
cell is one of three tiers (or supertypes) of 
basic objects in Forth. Other tiers of opera 
tions are based upon the double and the 
character (or byte). 

After the value associated with a cell or 
character value has been fetched onto the 
stack, other of the cell-oriented tier of 
operations can be applied, such as add, 
subtract, logical AND, logical OR, etc 
Ultimately, many different objects are 
manipulated by the same set of Forth op 
erators. In this way. Forth derives in- 
creased efficiency and compactness. 

The ease with which different object 
layouts can be homogenized for use with a 
(Continued on page 38.) 
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F83 

OBJECT-ORIENTED 

FORTH 

RICK HOSELTON - HOUSTON, TEXAS 



Once upon a time, while the sorceror 
was away, his apprentice magically made 
a broom carry water from a well into the 
house. When the job was done, the appren- 
tice didn't know how to stop the magic 
broom, so he chopped it into a thousand 
pieces. But then, each piece began to carry 
water. The house was flooded, and the 
apprentice almost drowned. The sorceror 
himself had to straighten out the mess. 

To write a complicated program, you 
definitely need to "chop it into pieces." 
But, as the sorceror' s apprentice discov- 
ered, chopping up a problem just any old 
way sometimes makes it worse! You need 
a technique for breaking programs into 
manageable pieces. 

How can you structure a program so 
that it is as simple as possible? Well, every 
useful program mimics some activity or 
event. An inventory program may simulate 
a warehouse operation; a game program 
might simulate an airplane flight or a poker 
hand. A program can't be simpler than the 
event it simulates. When your program's 
structure precisely matches the structure of 
the event it mimics, you have avoided use- 
less complexity. 

Events can be naturally divided into 
objects. For instance, an airplane flight is 
made of objects such as a plane, a pilot, and 
an airport. These objects act in ways deter- 
mined by their natures. Airports stay in one 
place, planes must take off before they can 
land. Objects interact. When a pilot ma- 
nipulates a plane's controls, he "sends a 
message" to the plane to bank or to climb. 
Complicated objects can be made of sim- 
pler objects. A plane can be considered to 
be made of an engine, control surfaces, etc. 

Matching a program's structure to an 



event's objects is called object-oriented 
programming. Some supporters of object- 
oriented programming believe that pro- 
grams should treat everything, even each 
location in memory, as an object. In prac- 
tice, "object orientation" is a matter of 
degree. Object programming is a style or 
philosophy, as much as a formula. 

Any computer language can be used to 
produce object-oriented programs, but 
some make it easier than others. Some 
programming languages, like Smalltalk, 
actually require an objectapproach. Forth is 
not a likely choice to rigidly enforce a 
programming discipline,but it can easily be 
extended to provide object programming 
support. 



^'Object program- 
ming is a style or 
philosophy, as much 
as a formula,'^ 



Objectives 

Following Forth's minimalist philoso- 
phy, the routine should be brief. It should 
meet the common goals of object program- 
ming, and allow programmers to extend 
and customize it for their own use. The 
routine must not interfere with the current 
capabiUties of Forth — the goal is to en- 
hance the powers of Forth, not to bury them. 

The routine must define objects to 
handle their own data with their own rou- 
tines (methods). An object may exchange 
information with other objects by sending 



and receiving messages. It shouldn't di- 
recUy access or change other objects' data. 
An object "obeys" or "acts on" messages 
by executing corresponding methods. 

The routine must define methods for 
the objects. A method is a routine an object 
uses to manipulate its data. Executing a 
method is the way an object responds to a 
particular message. The same message 
may be used in different ways by different 
objects. For example, two objects named 
GOLFBALL and TRUCK might have differ- 
ent methods for the message drive. The 
phrase DRIVE GOLFBALL would cause a 
completely different action than the phrase 
DRIVE TRUCK. 

The routine should support late bind- 
ing. Early binding means the system needs 
to know which object is to receive a mes- 
sage at the time it compiles the message 
call. With late binding, the application can 
wait until run time to decide which object 
should receive a message. The phrase 
ENTERMETHOD DECEMBER? 
IF ANNUALOBJECT 
ELSE MONTHLYOBJECT THEN 
would not work in an early binding system . 

The routine should support inheri- 
tance. Sometimes, a group of objects can 
respond to the same group of messages 
with the same methods. And sometimes, a 
group of objects must share some data with 
each other. It's convenient to describe such 
groups of objects as classes. Common 
methods and common data can be de- 
scribed just once for the entire class, in- 
stead of once for each object. This is called 
inheritance. 

Object Forth must execute quickly . If it 
is not fast, it is just not useful. 

(Text continued on page 34.) 
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e \ OBJECT PROGRP*^^:^S SUPPORT 'GOLS 3« Seotar.ber, 1S87 



i, »♦♦»♦♦♦♦♦♦♦♦♦♦♦♦«*#♦*♦♦«**♦♦««*♦»♦«*♦*♦♦♦♦♦♦♦♦♦♦##♦*♦♦♦♦♦♦» 

5 'he *oi lowing routine is piaced in the public 

5 oonain. I ::ve my perfiussiori for it to be used for 
7 any leiitiriHte purpose, free of charge. 

6 I sa;<e no warranty of any kind for this routine, and 
9 bear no respcinsibility wiatever ^or its use. 

li 

11 Rick F. Hoseiton 

12 

1* 

15 



\ Loading 

1 

e CREA^ flPPLICflTION 
3 

4 £ 9 THRU \ Object tools 

5 18 13 THRU \ Testing - Demonstration 
6 

7 

8 \S 
9 

16 This is a routine to assist FORTH programmers who 

11 »iant to produce "OBJECT ORIENTED' code. That phrase 

12 seets to mean different things to different people. 

13 Here is trfiat it means to me. 
14 

15 



14 

\ Data Structures: 



DFFSET tBY-ES METHOD format 

2 £ next oloer brother S<1ETH0D pointer 

£ £ lESSSGE nuiBber 

4 n l>ETH0D'5 code 

DFFSET #BYTES OBJECT format 

e 2 father OBJECT address 

£ £ youngest son OBJECT address + 4 

4 2 next older brother OBJECT address + 4 

5 £ youngest !€THQD address 
B n optional local data 



15 

\ Loading 

a "FORGETable" definition 

The wordset to rcake QBJECTs and NE'HODs work, 
fl demonstration. 



This routine is written to work with LftXflN i PERRY' s F83. 
Other FORTH implementations will probably reouire some 
chances. Especially, check ^E^HOD! fiCTIDN and ?Cf!tflTE. 



\ ftCTION 

CODE KTIOM i obj itsg - ! 

Rx POP u POP e « u m 

K6IN 8 CW] Um Z [W3 flX C«P 0= UNTIL 
4 I W fiDD [W] J!«!P END-CODE 



& 
7 
6 
9 
10 
11 
12 
13 
14 
15 



\S 



flCICW ( obj reg 

awp 6 + 

^IN g 2DIJP 2+ « 
4 + NIP EXECUTE ; 



iJNTIL 



\ Just like the CODE 
\ locate METHOD pointer 
\ searcn for equal f«ESSflGE 
\ execute the METHOD 



16 

\ ACTION 

This word finds the lESSflGE ori the given OBJECT'S 
«ETHOD-list and performs the corresponding METHOD 



This iiigh-'.eyel cefinition does the sase thing. 
It is provided for documentation, and for those who 
systems that aren't 6086 fasiily basse, 'he soeec loss 
does not seem to be critical. 
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t \ ACTION 

2 WRIflBLS '«S3 \ Current OSflSE # location 

3 

4 Wi?IflBL£ 'OBJECT \ Points to current OBJECT 

6 ! fiCT ( pfa IB55 — ) \ What i^ESSflGES do. 

7 EDUP 'I'SS 3 ! 'OBJECT 1 PCTIQN ; 
B 

g ; It ( ~ ?? ) \ Current OBJECT 

liZi ' OBJEC ? ! 

12 
J3 
14 
15 
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\ PCTION 

Joints to the last METHOD m the list. Placing the iCSSflGE 

number into this location ensures that a matcn will oe four* 
Points to the current OBJECT 

Setucr the OBJECT and HSS pointers, then so Derforin the 
METHOD requestec for this OBJECT. 

Place ciirrent OBJECT'S address onto tne stac<. 



Place current OBJECT'S FATHER'S address onto the stacK. 



4 

i \ Object acdressing 

£ 

3 : )uBJECT ( rel-addr — addr ) \ Locate in current OBJECT 

4 !»IE + ; 
5 

5 : ) SUPER ! rel-adcr — addr ) \ l.ocate m OBJECT'S parent 
7 HE § + i 

6 

9 : LINK, ( addr — ) \ Link here to addressee head 

Vi -lERE OVER C' , SWSP ! ; \ addr points here, here points 
11 \ where addr pointed 



la 

\ Object addressing 

Convert an OBJECT offset into a rieijory adcress. 

Convert an offset m the current OBJECT'S father into a 
rnefiiory address. 

Useful for buiidinc links, and ne use uariy. 



\ !«fiSTER 



19 

\ f^flSTER 



£ J OBJEC") { - ) 

3 ' OBJECT LINK, 

4 2 , 

5 2 ) SUPER L.INK, 
s S >SUQER e , ; 



\ rnake current and build father 
\ start with no sons 
\ link UD with brothers 
\ innerit METHODS 



For SuildinB OBJECTS. 



CREfl'E *fiS"ER 
«fiS'ER 'OBJECT : 
QBJECT) 

2 ) OBJECT & ERftSE 



\ make master the current 
\ Blaster is his own 'ather 
\ clear raaster 



"RSTS is the too ISSJiC in the systsns. 
even iiifiS'tR, are oescendents T^flS^tv 



14 
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(?1ETH0D: 
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\ (METHOD:) 





5 
6 
7 
B 
3 
18 

;i 
:£ 

■n 
14 
15 



iJIETHOD) ( — Eflsg ) 
CREATE DOESj ACT 



\ Build a ICSSaSE 



\ Get sSESSflSE nutiber 



''CSEflTE ( - tnsg ) 
) I** § BL WORD FINS 

IF Hi? )BODY ELSE DROP Jlf* ': immd) THEN ; 



!!1E^hQD:) t -- ) 
'C*?£fl'E 

6 ) OBJECT .INK, , 
[';!?] LITERAL , 
'CSP ] ; 



\ Be save ?!ESSfiGE exists 
\ Link tnis MESSAGE nuifiDer 
\ Eriter colon defiriitior: 
\ compile this i^ETHQD 



Build a MESSAGE header, aM leave the PFfl on tr\e stacK. 
At run tine, the MESSflffi will (CT. 

If a !€SSfiGE nas not Deen defirsd, defire it. 
Eitiier way, leave the CIEBSfiSE nuaber (parameter fieic address) 
on the stack. BE CAREFUL to; to use a for a l€SSAGE that 
nas already been used for anything but a sessage: 

Set (or create) the MESSAGE nuaber. 

Cosipile tnis SESSAGE number and link up the METHOD chain. 

Compile the code for this i€THOD. 



7 

\ MASTER METHOD'S 
1 

2 \ The system's base l<!ETHOD 

3 (METHOD:) AliCHOR ." I don't understand" ; 

4 ' tt^iCHOR >BaDY £+ '«S6 ! 

-J 

6 \ Building a METHOD is a METHOD 

7 (METHOD:) fiETHOD: ( - ) 

8 (METHOD:) ; 
9 

Vi \ Building a rew OBJECT is a fiETHOD for the parent 
11 MAS'ER METHOD: OBJECT: ( - 1 
1£ CREATE OBJEC") ; 



21 

\ MASTER METHODS 

ANCHOR is always at the end of the iCTHOD chain. 

Its MESSAGE nuaber is set by ACT to the current SSSAGE. 

So, if P£l firids no other siatching ICTHOD, it uses this one. 

This is the default METHOD for building ME'HOD's. 
OBJECT'S can have a different METHOD: if you define one. 



■^his IS the default J'ETHOD for defining OBJECT'S. 
You isay define a different OBJECT: to build 
more cofplex tyoes of OBJECT'S. 



1 \ .METHODS 

2 : .?f!ETHOD ( link — ) 

3 CS DUP 6 y.S DUP C & U.R 

4 £+ 5 DJP 6 U. S 2 SPACES BODY) )NAM£ .ID 

tr 

6 MflS"ER met:hod: .-IETHODS ( " ) 

7 KSE ? HEX 6 > OBJECT 

8 BEGIN 9 WJP iiHILE DUP .METHOD REPEAT 
3 BASE ! ; 

1? 
11 
l£ 
.3 



\ .METHODS 

Display the name of a METHOD. 



Displays all the METHOD'S tnat have oeen cefi?ieo for the 
current OBJECT. 



(Screens continued on page 33.) 
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CALL FOR PAPERS 

for the tenth annual 

FORML CONFERENCE 

The original technical conference 
for professional Forth programmers, managers, vendors, and users. 

Following Thanksgiving, November 25-27, 1988 

Asilomar Conference Center 
Monterey Peninsula overlooking the Pacific Ocean 
Pacific Grove, California U.S.A. 

Theme: Forth and Artificial Intelligence 

Artificial intelligence applications are currently showing great promise when developers 
focus on easy-to-use software that doesn't require specialized expensive computers. Forth's 
design allows programmers to modify the Forth language to support the unique needs of 
artificial intelligence. Papers are invited that address relevant issues such as: 

Programming tools for AI 
Multiusers and multitasking 
Management of large memory spaces 
Meeting customer needs with Forth AI programs 
Windowing, menu driven or command line systems 
Captive Forth systems — operating under an OS 
Interfacing with other languages 
Transportability of AI programs 
Forth in hardware for AI 
System security 

Papers about other Forth topics are also welcome. Mail your abstract(s) of 100 words or 
less by September 1, 1988 to: 

FORML 
P. O. Box 8231 
San Jose, CA 95155 

Completed papers are due by October 15, 1988. For registration information call the Forth 
Interest Group business office at (408) 277-0668 or write to FORML. 

Asilomar is a wonderful place for a conference. It combines comfortable meeting and 
living accommodations with secluded forests on a Pacific Ocean beach. Registration 
includes deluxe rooms, all meals, and nightly wine and cheese parties. 
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fig-FORTH 

STEP-TRACING 

IN fig-FORTH 



GENE THOMAS - LITTLE ROCK, ARKANSAS 



T_Tser's of Laxen and Perry's F83 
have a stepping utility invoked by the word 
DEBUG. It steps through definitions, dis- 
playing the stack contents at each step 
every time a key is pressed. Users of fig- 
FORTH and its derivatives have no such 
utility inherently resident in their systems. 

During a meeting of the central Arkan- 
sas chapter of the Forth Interest Group, 
someone noted how nice it would be if fig- 
FORTH definitions could be stepped 
through; they suggested redefining ; 
(semi-colon). Those with a fair degree of 
Forth experience — and perhaps even 
novices, after a moment's reflection — will 
see that attempting to define 
: ; KEY DROP ; 

will result in a problem as soon as the first 
semi-colon is encountered by the compiler. 
Even if the above definition was renamed 
to [ ; ] and additions made it a workable 
replacement for ; , a lot of editing work 
would be required to insert the new word 
when needed and to remove it when done. 
When I started this project, I made a rule: 
the finished application must not require 
any editing when it is used. 

The Solution 

The solution I finally arrived at uses : 
(colon) rather than ; (semi-colon), and 
vectored execution "tricks" the colon into 
being redefined. This has three advantages 
over the other methods I tried. First, no 
debugging word needs to be edited in and 
out. Second, stepping mode can be toggled 
on and off without recompiling. Third, the 
colon itself does not have to be recompiled. 

Listing One is the step-trace applica- 
tion. Listing Two contains a few support 
words, which must be loaded before the 



code in the first listing if your system 
doesn't already have them. 

Now let's examine the step trace code, 
beginning with screen three of Listing One. 
The word DEBUG is executed and the rou- 
tine to be debugged is recompiled. 
Executing DEBUG replaces the value in the 
firstPFA address (COL: ADR) of : (colon) 
with the CFA of [ : ] (STEP : VAL). The 
definition of [ : ] beginning on line 18 will 
now be used when a colon is encountered in 
definitions compiled after debug execu- 
tion. The remaining PFA addresses in the 
definition of : will not be executed because 
of the R> DROP on line 25. 



"f.-J will now be 
used when : (colon) 
is encountered,.,^' 



The stepping function will be taken care 
ofwhenSTEP?iscalledby [ : ] (STEP?'s 
CFA was pushed into [ : ] on line 23). 
When STEP? is called (see line 7), the 
variable do-STEP? is checked to see if 
words are to be stepped; if so, it uses the top 
of the return stack to display the name of the 
word and displays the contents of both 
stacks. STEP? then stops and waits for a 
keypress (line 11). If the keypress is a B (or 
b), BREAK is executed; otherwise, the next 
word is stepped. (See FD V/1 for a full ex- 
planation of the BREAK/GO tool in screen 
two of Listing Two.) 

Here is how : (colon) would look if 
decompiled before execution of debug: 



: : ?EXEC !CSP 
CURRENT CONTEXT 
CREATE (;C0DE) 

HERE 2- ! ] 

IMMEDIATE 

And, after executing DEBUG: 
: : [:] !CSP 

CURRENT CONTEXT ! 
CREATE (;CODE) 

HERE 2- ! ] 

IMMEDIATE; 

But, because of the construction of 
[ : ] , the debug version of : acts as if it 
were defined like: 
: : [ : ] ; IMMEDIATE 

Thus, through the magic of vectored 
execution, we are able to toggle between 
two alternate versions of : (colon), com- 
piling under whichever we choose. 

The default state of step? is off. 
After compiling a routine for use with 
DEBUG, the word step is executed to 
toggle to the stepping mode, s tep may be 
called as often as desired. Whenever you 
are unsure whether compiling is set to 
normal or to debug, invoke ? S TEP to find 
out. Of course, the normal compiling 
condition of the colon is restored by 
RESTORE: COL. 

A display of the return stack contents 
is of little value unless there is an easy way 
to identify the word to which those num- 
bers (PFA return addresses) belong. 
While in the BREAK state, or at any time 
when not executing, the word NAME on 
screen four of Listing One will provide the 
needed information. Feeding any valid 
address from a parameter field to name 
will produce the name of the word to 
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which that parameter field belongs. Some- 
times the return stack contains items like 
DO LOOP indices. Giving NAME an invalid 
PFA has never crashed my system, but a 
memory check location in addition to 
DEF-END could be added to stop name 
when the bottom of the dictionary is 
reached. It is also well to remember that a 
return stack number may be equivalent to a 
PFA address and yet not actually be one. A 
DO LOOP index, for example, may be equal 
to some PFA address. Actually, NAME will 
respond correctly when given any address 
from a word's dictionary entry, except the 
last PFA address containing the CF A of ; S 
(EXIT). In that case, name will produce 
the name of the following word in the 
dictionary. 

Four words in the step- trace application 
are intended to be executed from the 
keyboard: STEP, STEP?, 
RESTORE : COL, and DEBUG. The words 
NAME, BREAK, GO, . S, and . RP are inde- 
pendent of the step trace in the same way as 
words like R> and DROP. 

When you are debugging the step-trace 
application itself, avoid crashes by 
executing RESTORE: COL before forget- 
ting and recompiling. After the step trace is 
up and running, crashes will not occur if 
you forget to RESTORE : COL and recom- 
pile the routine you are debugging. 

Compatibility 

The definition of NAME assumes that 
each dictionary entry's LFA is followed by 
its NFA. If the NFA comes first in your 
system, change the 4 + on line 57 to 2+. 

The definition of . RP assumes that the 
return stack grows downward in memory; 
an adjustment will be necessary for systems 
in which that stack grows upward. 

I believe the definition of [ : ] will work 
in most systems, even if the : colon is 
defined differendy than in fig-FORTH. If 
not, you will need to decompile your colon. 
Using that decompilation, insert the code 
on lines 21-25 at the appropriate place. 



Listing One. 



Gene Thomas edits the Comment Line, 
the newsletter of the Central Arkansas 
FIG Chapter, and is a registered poly- 
somnographic technologist at the Sleep 
Disorders Center at the University of 
Arkansas for Medical Sciences. 



1. 

2. 

3. 

A. 

5. 

6. 

7. 

8. 

9. 
16. 
11. 
12. 
13. 
14. 
15. 

16. 
17. 
18. 
19. 
26. 
21. 
22. 
23. 
24. 
25. 
26. 
27. 
28. 
29. 
3B. 
31. 

32. 
33. 
34. 
35. 
36. 
37. 
38. 
39. 
4&. 
41. 
42. 
43. 
44. 
45. 
46. 
47. 



I inning scr #43 
\ Scr «i: Step trace 

VARIABLE DQ-STEP? 
: STEP \ — I user; toggle step mode 

SPACE ." Step is " DO-STEP? DUP Q 
IF OFF ." o-ff." 

ELSE ON . " on . " 
THEN ; 

: STEP? \ — : vectored to from I'J 



Gene Thomas Feb86 



Toggle ii display 
If on, turn off 
If off, turn on 



DO-STEP? @ 

IF CR R ( Re) 
CFA NFA ID. 
.S .RP KEY DUP 
SWAP 98 = OR 
IF BREAK THEN 

THEN ! 



\ Step mode on? 

\ If so copy pfa adr 

\ Display name and stacks 

66 = \ then stop and await key 

\ press before continuing 

\ If key = B or b then 

\ break, else continue 
stepping cycle 



\ Scr #2: Step trace 

' : CFA @ CONSTANT CFA: 
' Z'2 \ — I setup to vector colon for step execution 
?EXEC !CSP CURRENT @ CONTEXT ! CREATE 
\ normal definition of colon to here 



gt Feb86 



cfa in 



cfa: \ 

HERE 2- I \ 

' STEP? CFA DUP @ \ 

HERE 2- I , \ 

R> DROP ] i \ 
remind CR ." Re-compile under current colon." 
e VARIABLE STEP-MODE 

?STEP \ — 'user; show compiling condition: normal /debug 
CR ." Compiling " STEP-MODE 6 IF . " under step mode 
ELSE . " under normal mode. " THEN ; 



Inserts your colon's 
next adr 

Insert stepping instruction 
in the next adr 
Drop ret adr to original col 



\ Scr #3: Step trace 

' C:] CFA CONSTANT STEP:VAL 

' : e CONSTANT col:val 

' : CONSTANT col: PFA 



gt Feba6 
\ Vectors used by debug 
\ and restore: col 
\ Contents toggled by 
\ debug and restore: col 



REST0RE:C0L \ — I user; set for normal compiling 
remind C0L:VAL C0L:PFA ! STEP-MODE OFF ; 

— 1 user; set for compileing under step vector 
STEP:VAL col: PFA ! STEP-MODE ON ; 



: DEBUS \ 
remind 

To debug: forget routine if not compiled under debug mode, 
execute DEBUG and re-compile the routine. Routine can now be 
run under STEP (step on ok), or STEP (step off ok). When 
debugged: forget routine, execute REST0RE:C0L and recompile. 
Definitions are now compiled under normal conditions. Step 
Trace screens can remain in system. 



Beginning scr #46 

48. \ Scr #4; Step trace augment 



49. 




50. 


' ;S 


51. 




52. 


: NAME 


53. 




54. 


CR 


55. 




56. 




57. 




58. 




59. 


ir 


60. 




61. 




62. 




63. 


END 



GT maySS 
EXIT in some systems 



\ any-pfa-adr 



BEGIN 
2- DUP @ 
DEF-END = 
UNTIL 4 + 
Adr is in: 



I user; show name of word to which pfa 
\ belongs - is an independent word 



\ Find end of prev diet entry 
\ and jump forward to nfa 



ID. ; \ Show name of word pfa is in 

TI-FQRTH, an extension of FIG FORTH 

Step trace 
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(Thomas's screens, from previous page.) 



Begi 

1. 

2. 

3. 

4, 

5. 

6. 

7. 

8. 

9. 
10. 
11. 
12. 
13. 
14. 
15. 

16. 
17. 
18. 
19. 
21). 
21. 
22. 
23. 
24. 
25. 
26. 
27. 
28. 
29. 
30. 
31. 



nning scr #41 

\ Scr #1; Non-destruct return stack display GT may85 

Some de-f ' s you may need 

: .RP \ — 1 user; display contents o-f return stack 
BASE @ HEX \ Save base 

CR RP@ 2- m @ 2- ." Rl " \ Set limits o-f r-stack 
DO I e U. -2 +LOOP \ Display contents 

BASE ! : \ Restore base 



■ S 

Alternate de-f for .RP 

: .RP BASE @ HEX R0 8 2+ RP@ DO I @ U. 
LOOP BASE ! ; 
(r-stack grows up in memory: 



( 2 -fLOOP) 



Gray Smith) 



RP@ +or TI-FORTH users (load scr #74, code): 
HEX CODE RP@ 6649 , C64E , e45F DECIMAL 



Scr #2: Step trace support; modi-fied for Step Trace, gt 
Break point tool -from Forth Dimensions vol V no. 1 



\ Debugging tools: BREAK ?< GO 
\ by Frank Seuberling, 5/4/81 

e VARIABLE CHECK 
: BREAK ( — ) CR RP8 4 - 

e BLK I 

BEGIN 

QUERY INTERPRET ." aok 
AGAIN ; 
: GO ( — 
IF R> 

ELSE 
THEN \ 

sS END 



WF 



13DEC81 KRH 



CHECK 



CR 



) RP@ CHECK e 
DROP R> DROP 
. " Can't resume" 



QUIT 



R-stack security 
Take input -from 
terminal 



R-stack security 
Resume e>;ec prog 
unless rp@ has 
changed 

Step Trace Support 



(Page's screens, from page 11.) 



ASSEMBLER SCR « 9 

\ More mnemonics and special definitions 09MAR88CHP 

1 90 BRANCHES BCC , BO BRANCHES BCS , FO BRANCHES BEQ, 

2 30 BRANCHES BMI , DO BRANCHES BNE , 10 BRANCHES BPL , 

3 50 BRANCHES BVC , 70 BRANCHES &JS , 

4 : JSR, SP3 SO 4 - = IF SIaJAP LABEL. SAVE THEN DUP 20 C , , 

5 DUP 200 U< SWAP 100 U< 0= AND IF REF. POINTER 3 DUP SWAP C! 

6 \ I-f 100 < addr < 200 then it is a label 

7 1+ HERE 2- SWAP I \ Saye compilation address 

8 3 REF. POINTER * '. THEN ; 
9 

10 
1 1 
1 2 
13 
14 
15 



IMMEDIATE 



. , SP3 SO 4 - = I F SWAP LABEL . SAVE THEN , ; 
C , , 3P3 SO 4 - = I F SWAP LABEL . SAk^E THEN C , ; 
END SECOND. PASS CURRENT 3 CONTEXT ' ?EXEC ?CSP 
60NEXT ['] NEXT >BODY JMP , ; 

' ' >BODY JSR, ; --> \ Use-ful in composite primitiyes 
\ e.g., ASSEMBLE PR0(3RAM A ' B * C 80NEXT END 



ASSEMBLER SCR # 10 
\ Assembler concluded 
1 

2 FORTH DEFINITIONS 

3 

4 ! PRIM -2 ALLOT HERE 2* , ; 
5 

6 : ASSEMBLE ?EXEC CREATE ASSEMBLER PRIM 

7 [ ASSEMBLER I CLEAR. TABLES ZP I CSP ; 

8 

9 IMMEDIATE 
10 

11 DECIMAL 

12 

13 

14 

15 
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(Letters continued on page 32.) 



BRYTE I 
FORTH I 

INTEL I 
8031 I 

\ micro- 
controller! 




FEATURES 

— FORTH-79 Standard Sub-Set 
—Access to 8031 features 
—Supports FORTH and machine 

code interrupt handlers 
—System timekeeping maintains 
time and date with leap 
year correction 
—Supports ROM-based self- 
starting applications 



COST 

130 page manual — $ 30.00 
8K EPROM with manual— $100.00 

Postage paid in North America. 
Inquire for license or quantity pricing. 



Bryte Computers, Inc. 

P.O. Box 46, Augusta, ME 04330 
(207) 547-3218 
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fig-FORTH 

LINEAR 

AUTOMATA 

ANDREAS CARL - RERUN, WEST GERMANY 



T. 



. he idea for the following program is 
from A.K. Dewdney in Scientific Ameri- 
can (German edition, July 1985). He 
writes, "In a world of artificial computers, 
it is surprising to imagine that we might be 
surrounded by a variety of natural com- 
puters like water, wind, or wood. Such 
natural systems don't calculate in a con- 
ventional way, of course, but their struc- 
ture makes arithmetic abilities a hidden 
possibility. Stephen Wolfram, physicist at 
the Institute for Advanced Study in Prin- 
ceton, is as advocate of this thesis. He is of 



^^Cellular automata 
can calculate and 
simulate natural sys- 
tems/' 



the opinion that a turbulent fluid or a 
growing plant are built of simple ele- 
ments, but in the whole are so complicated 
that behavior cannot be reduced to mathe- 
matical terms. This irreducibility means 
they can store, transfer, and process infor- 
mation — they can calculate!" 

To demonstrate the arithmetic abilities 
of natural systems, he uses cellular auto- 
mata. In looking for cellular automata 
which can both calculate and simulate 
natural systems. Wolfram confines him- 
self to the simplest automata, those of one 
dimension. 

These linear automata are defined by 
two constants and a set of rules, which 
define the transition from one generation 
of cells to the next k gives the number of 
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states a cell can have; usually, it is two (to 
be or not to be), r is the radius; it deter- 
mines the number of adjacent cells that 
will influence the subsequent state of a 
cell. 

A table of rules gives the state of the 
next generation for every possible con- 
figuration. For example, for /: = 2 and r = 
2, there might be a rule which determines 
that a configuration like 0-1-0-1-1 leads 
the middle cell to become 1. For 
simplicity's sake, we can refrain from 
rules that Wolfram calls "total." Thus, a 
cell's next state depends only on the sum of 
the current states of all cells within radius 
r. In the example above, the sum can be 
between zero and 5, so a table of rules 
might look like: 

Sum: 5 4 3 2 1 

Next state: 10 10 

If you read the next-state line as a binary 
number (e.g., 10100, which is 20 = 2^ -i- 2"), 
you get the code of the rules. So this "linear 
automaton" is characterized by k=2, r=2, 
code=20. There are 64 different codes 
(tables of rules) for k=2 and r=2. 

Now, if you apply this automat to the 
starting pattern 10111011, you will see 
that it moves like a signal to the right. In the 
world of this automat, it is a signal. Try to 
find other signals, patterns which produce 
or consume signals, and see what happens 
when two signals hit each other. 

Try the automaton with )t=2, r=3, and 
code=SS on the starting pattern 
1111111111011. This is the famous can- 
non by J.K. Park: a signal-producing pat- 
tern which "shoots" to both directions 
every 1 19 generations. Good luck hunting 
for patterns! 

Glossary 

It should be fairly easy to convert the 
accompanying fig-FORTH screens into a 
dialect which will run on your computer. 
All you need is a Forth system with graph- 
ics capabilities. 

PLOT (xy--) 

Plots a point at the coordinates (x,y). 
?PLOT (xy--f) 

Returns a flag, depending on whether a 
point is set or not. 



SUMME 

Calculates the sum of states for a given x 
coordinate. 

RE I HE 

Compares SUM with KODE to decide 
whether to plot a point for any of the 320 x 
coordinates. 

AUTO 



Calculates the new generation for any of 
the 199 y coordinates. 

SET 

Sets a starting pattern into the first row 
(y=0) of the graphics display (bit map). 
(The address provided in llie definition of 
this word is specific to the Commodore- 
64 on which it was written.) 



fSCR 01 

( LINEAR AUTOHAT ) 

1 

2 VARIABLE Y Vft?IABLE SIM 

3 VARIABLE RADIUS VARIABLE KOOE 
4 

5 : DUAL 2 BASE ! ; 
6 

7 : SUmE RADIUS e DUP 1+ swap -l « do ZDUP swap I + SMAP 

8 ?PLOT 0= IF ELSE SUH i 2 ♦ SUH ! ENDIF 

9 LOOP 2DR0P ; 

10 

11 : REIHE 320 DO I Y § 1 SUH ! SUHME 

12 sun e KOOE e and 

13 IF I Y § 1+ PLOT ENDIF 

14 LOOP ; -> 
15 



fSCR 02 

( COHT. ) 

1 

2 : AUTO 199 DO I Y ! REIHE LOOP ', 
3 

4 : SET 256 /HOD 8352 C! 83G0 C! DECIMAL ; 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
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Real-Time Programming 
Convention 



November 18 - 19, 1988 
Grand Hotel, Anaheim, Califomia 

Call for Presentations 



The 1988 Real-Time Programming Convention will be held at the Grand Hotel in Anaheim, 
Califomia, and is sponsored by the Forth Interest Group. 

The theme of this year's convention is Real-time Programming Systems. The invited 
speakers are Jef Raskin, head of the original Macintosh development team and inventor of 
the Canon Cat, and Ray Duncan, well-known author and expert on IBM PC Operating 
Systems. Both speakers have made extensive use of Forth, a language especially suited to 
real-time applications. 

There is a call for presentations on topics in the following areas: 



Programming Environments 



Applications 



Real-time Operating Systems 

Language-oriented RISC machines 

Parallel Processing 

Languages for Data Acquisition and 

Analysis 

Robotics and Real-time Device Control 
Intelligent Devices 



Aerospace 

Medical 

Laboratory 

Machine-vision 

Digital Signal Processing 

Robotics 

Automation 

Instrumentation 



Intelligent Instrumentation 
Working Neural Nets 
Adaptive devices 
Software Peripheral Controllers 



Presentations may be either talks or demonstrations. Talks are limited to fifteen minutes. 
Please submit an abstract of the talk and a request for any audio- visual assistance by October 
15. Demonstrations may accompany the talk or appear separately throughout the 
convention. Please send a description of the demonstration and its requirements by October 
15. 

Abstracts and descriptions should be sent to: Real-Time Programming Convention, 
Forth Interest Group, PO Box 8231, San Jose, CA 95155. 
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Volume Eight Index 

A comprehensive reference guide to all issues of Forth Dimen- 
sions published during the Volume Vin membership year. (Spe- 
cial tlmnks to indexer Mike Elolaof San Jose, California.) See the 
FIG Order Form to order complete sets of back issues. 



Algorithms 
CRC 

XMODEM Tutorial, Vol 8, Issue 2, pg 9 
Checksums 

Checksum More, Vol 8, Issue 6, pg 40 
Random Number 

Shuffled Random Numbers, Vol 8, Issue 3, pg 31 
Sorting 

Batcher's Sort 
Batcher's Sort, Vol 8, Issue 4, pg 39 
XMODEM Protocol 

XMODEM Tutorial, Vol 8, Issue 2, pg 9 
Graphic/Plotting 

see Graphics 
Architectures 

Letter, Vol 8, issue 5, pg 9 

32-bit 

Letter, Vol 8, issue 1, pg 5 
Forth Virtual Machine 

The Multi-Dimensions of Forth, Vol 8, Issue 3, pg 32 
Assemblers 

The Multi-Dimensions of Forth, Vol 8, Issue 3, pg 32 

Benchmarks, Performance 
Sieve of Primes 

Letter, Vol 8, Issue 6, pg 31 
Letter, Vol 8, Issue 4, pg 5 
Letter, Vol 8, Issue 4, pg 6 
Letter, Vol 8, Issue 2, pg 5 
Bulletin Boards 

Forth Resources via Modem, Vol 8, Issue 2, pg 25 

Common Usage 

A Forth Standard?, Vol 8, Issue 4, pg 28 
Compiled Code, Development Utilities for 
LOCATE source code 

On-Line Documentation, Vol 8, Issue 2, pg 21 
Letter, Vol 8, Issue 5, pg 6 
Testing 

using Assertions 
Letter, Vol 8, Issue 6, pg 4 
Compilers 
File-based 

Letter, Vol 8, Issue 5, pg 7 
Screenless Forth, Vol 8, Issue 5, pg 13 
Macro Compilers 

Synonyms and Macros, Part 4: Compiler Macros, Vol 8, 
Issue 3, pg 5 



SYNONYMS 

Letter, Vol 8, Issue 1, pg 5 
Letter, Vol 8, Issue 6, pg 9 
Letter, Vol 8, Issue 6, pg 10 
Compiler Directives 
Control Flow 
CASE 

The Ultimate CASE Statement, Vol 8, Issue 5, pg 29 
DO-LOOP 

Letter, Vol 8, Issue 1, pg 6 
LEAVE 
Letter, Vol 8, Issue 3, pg 10 
Letter, Vol 8, Issue 4, pg 9 
Recursion 
Letter, Vol 8, Issue 5, pg 5 
Conferences 

Editorial, Vol 8, Issue 1, pg 6 
FORML '86 in Review, Vol 8, Issue 6, pg 38 
Conventions 

Editorial, Vol 8, Issue 1, pg 6 

National Forth Convention '86, Vol 8, Issue 5, pg 34 

Data Structures within the Forth Dictionary 
Screen Fields 
LOCATE 

On-Line Documentation, Vol 8, Issue 2, pg 21 
Parameter Fields 
Threaded Code 
Forth Systems With a Segmented Memory Model, 
Vol 8, Issue 3, pg 2 
Data Records and Associated Operations 
Select, Ordered, Perform 

Select, Ordered, Perform, Vol 8, Issue 1, pg 22 
Maintenance Operations (add, delete, etc.) 

The Point Editor, Vol 8, Issue 3, pg 15 
Editing 

The Point Editor, Vol 8, Issue 3, pg 15 
Querying 

Data Structures and Associated Operations, 
Vol 8, Issue 4, pg 17 
Sparse Arrays 
Lookup 

A Simple Translator Tinycase, Vol 8, Issue 5, pg 23 
Data Types and Associated Operations 
Characters, byte 
Case Conversion 

Case Conversion in KEY, Vol 8, Issue 1, pg 21 
Integers, cell 

Comparison Operations 

The Ultimate CASE Statement, Vol 8, Issue 5, pg 29 
Formatted Output 

Letter, Vol 8, Issue 1, pg 6 

Letter, Vol 8, Issue 4, pg 6 
Masking off Bits 

Letter, Vol 8, Issue 4, pg 6 
Square Root Algorithms 

Letter, Vol 8, Issue 4, pg 8 
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Trigonometric Functions 

Fast Fixed-Point Trig, Vol 8, Issue 1, pg 14 

Letter, Vol 8, Issue 4, pg 10 
Integers, double 
Arithmetic 

Letter, Vol 8, Issue 2, pg 5 
Trigonometric Functions 

Letter, Vol 8, Issue 1. pg 5 
UM/MOD 

Unsigned Division Code Routines, Vol 8, Issue 6, pg 18 
Integers, quad 
Arithmetic 
Letter, Vol 8, Issue 2, pg 5 
Real Numbers 
Arithmetic 

Practical Considerations for Floating-Point, 
Vol 8, Issue 5, pg 10 
Strings 
Parsing 

Dual-CFA Definitions, Part Two, Vol 8, Issue 4, pg 13 
Letter, Vol 8, Issue 4, pg 5 
Decomposition of Functions 

Dual-CFA Definitions, Vol 8, Issue 2, pg 30 
Deferred Definitions 

Dual-CFA Definitions, Part Two, Vol 8, Issue 4, pg 13 
Simple FUe Query, Vol 8, Issue 4, pg 17 
Disk OS Structures and Associated Operations 
File Control Blocks (FCBs) 

DOS File Disk I/O, Vol 8, Issue 6, pg 19 
Data Files for Forth Screens 

DOS File Disk I/O, Vol 8, Issue 6, pg 19 

Education 

Letter, Vol 8, Issue 2, pg 8 

Letter, Vol 8, Issue 5, pg 5 
Error Processing 

XMODEM Tutorial, Vol 8, Issue 2, pg 9 

Games and Recreation 

Tracking the Beast, Vol 8, Issue 5, pg 15 
7776 Limericks, Vol 8, Issue 6, pg 28 
Graphics 

Plotting of Lines 

The Point Editor, Vol 8, Issue 3, pg 15 
The Bresenham Line-Drawing Alogirthm, 
Vol 8, Issue 6, pg 12 
Plotting of Functions 

Windows for the TI 99/4A, Vol 8, Issue 4, pg 34 

Hardware 

Integrated Circuits 

Moore Chats on CompuServe, Vol 8, Issue 1, pg 25 
Letter, Vol 8, Issue 5, pg 9 

History, Forth 

A Forth Standard?, Vol 8, Issue 4, pg 28 
State of the Standard, Vol 8, Issue 6, pg 34 



Information Services 

Forth Resources vi Modem, Vol 8, Issue 2, pg 25 
Interpreters 
SYNONYM 

Letter, Vol 8, Issue 1, pg 5 
Forth (words) 

Dual-CFA Definitions, Part Two, Vol 8, Issue 4, pg 13 
Interrupts 

TI 99/4 A ISR Installation, Vol 8, Issue 1, pg 23 
Libraries 

A Forth Standard?, Vol 8, Issue 4, pg 28 
Letter, Vol 8, Issue 5, pg 6 

Marketing 
Forth 

XMODEM Tutorial, Vol 8, Issue 2, pg 9 
Letter, Vol 8, Issue 3, pg 5 
Letter, Vol 8, Issue 5, pg 6 
Editorial, Vol 8, Issue 5, pg 9 

Memory 
Segmented 

Letter, Vol 8, Issue 1, pg 5 

Forth Systems With a Segmented Memory Model, 

Vol 8, Issue 3, pg 12 

Natural Languages 

Letter, Vol 8, Issue 4, pg 5 

Operating Systems 
Interfacing with Forth 

DOS File Disk I/O, Vol 8, Issue 6, pg 19 
Portability 

Moore Chats on CompuServe, Vol 8, Issue 1, pg 25 
Letter, Vol 8, Issue 3, pg 8 

The Multi-Dimensions of Forth, Vol 8, Issue 3, pg 32 
Programming Languages and Methodologies 

Forth, philosophy behind 

Dual-CFA Definitions, Vol 8, Issue 2, pg 30 

The Multi-Dimensions of Forth, Vol 8, Issue 3, pg 32 

Dual-CFA Definitions, Part Two, Vol 8, Issue 4, pg 13 

Object Oriented 

Classes in Forth, Vol 8, Issue 5, pg 24 

Scope 

Local Variables 

Stack Numbers by Name, Vol 8, Issue 3, pg 36 
Source Code 
Editing of 

Letter, Vol 8, Issue 2, pg 6 

Getting Started with F83, Vol 8, Issue 4, pg 37 

Formatting 

Forth Source Formatter, Vol 8, Issue 2, pg 27 
Libraries 

Letter, Vol 8, Issue 1, pg 6 
Standards 

ANSI Forth 
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The Ultimate CASE Statement, Vol 8, Issue 5, pg 29 

Terminal Emulation 
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Testing 

via Assertions 
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Threaded Code 
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Tutorials 

XMODEM Tutorial, Vol 8, Issue 2, pg 9 
Getting Started with F83, Vol 8, Issue 4, pg 37 

User Groups 
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User Interface 
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Windows 
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F83 USERS 



PVM83 is a complete Prolog extension to Laxen and Perry F83. 
It handles the primary data structures of strings.numbers.logical constants, 
logical variables, compound predicates, and lists. PVM83 is designed to add 
productivity and flexibility. It is tully interactive between Prolog procedures, 
and Forth code. PVM83 is a compiled Prolog featuring fast execution times. 

PVM83 is fully extensible. "Standard" definitions gives the 
programmer flexibility to design just those procedures needed for his 
application. PVM83 code can execute Forth words. F83 can call the PVM83 
backtracking and problem solving capabilities. 



PVM83 code is Incrementally 
compiled in higher memory segments 
than the F83 core, leaving room in 
the F83 kernal for the "standard" exten- 
sions or other F83 code that the pro- 
grammer needs. 

PVM83 is designed to keep the 
Forth philosophy of being both 
compiled, and interactive. You can type 
in procedures from the keyboard and 
test them, or supply source code from 
Forth block files, or text files 
Intersegment memory management 
source code included. 



I PVM 83 

only $69.95 
includes manual 

requires 
DOS 2.0 or higher 256K RAM 

Concept 4 

PC Box 20136 
VOC Az 86341 
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THE BEST OF 

GENIE 

GARY SMITH - UTTLE ROCK, ARKANSAS 



^Jews from the GEnie Forth 
RoundTable: Beginning July 10, the Sun- 
day on-line meetings at the "Figgy Bar" 
will feature a question-and-answer session 
for novices, with Leonard Morgenstem as 
chair for these tutorial conferences. 

Since it is not unusual to see lOK or 
more of new messages on a given day, and 
this column is limited in size, you are only 
getting a peek at recent on-line activity. 
This time, the peek will be into the very 
lively standards category (Category 10). 

Some still may not realize the X3/J14 
Technical Committee has made the GEnie 
Forth RoundTable their home service. X3/ 
J 14 has the task of drafting a ANS standard 
Forth. Here, the very future of our language 
isbeing debated with a grand mix of knowl- 
edge, wisdom, and humor. This excerpt 
features a discussion centered around a 
proposal by Lee Brotzman. I hope it will 
encourage you to get involved. 

Category 10, Topic 23, Message 76 
Wed Mar 23, 1988 S.W.SQUIRES 
[scottl 

Lee, I have some of the same suggestions 
that Leonard does for your file words. How 
about: 

OPEN ( addr - - file# ) 

File# could be a number or a handle or 
pointer or fcb or whatever would be in 
keeping with the specific computer/Forth 
system as long as it is consistent on that 
system. On a one-file limited system it 
would just leave the same number. Mul- 
tiple files have been the norm for some time 
even in the simple Forth systems I've used. 
Typical case is reading in one file, manipu- 
lating it and writing it back out to another 
file. 
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CLOSE ( file# - - ) 

READ ( addr nl file# - - n2 ) 

WRITE ( addrnl file# -- n2 ) 

SEEK and FILEPOS would require a 
file# as well. Would it be more beneficial to 
provide pointers with the READ and 
WRITE commands? I.e., READ ( addr nl 
file-offset file# - - n2 ) The more primitive 
the words, the more flexible they could be. 
Same thing with flags — would it just be 
more straightforward to leave a flag after 
every disk operation? 

How about a create-file function? 
You'd probably need to provide a size 
parameter as well as an addr of the naming 
convention to allow for systems with un- 
expandable file sizes. 

How about a request for the file size? 
This would allow a program to set aside the 
correct buffer size and to use the size for 
any calculations. — Scott 

Category 10, Topic 23, Message 77 
Thu Mar 24, 1988 L.BROTZMAN 

Leonard and Scott, 

Jerry Shifrin voiced the same concerns 
as yours when I uploaded my proposal to 
the East Coast Forth Board. I'll just repro- 
duce my answer to him here: 



Date: 03-23-88 (11:57) Number: 276 
To: SYSOPRefer#: 273 
From: LEE BROTZMAN Read: YES 
Subj: HOST HLE ACCESS PROPOSAL 
Status: PUBLIC MESSAGE 

Yes, Jerry, I purposely avoided the 
subject of multiple files since I think that 
trying to pass file handles, of reference 
numbers or whatever, is so system specific 
that it becomes very difficult to standard- 
ize. This proposal is hard enough to get 
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adopted as is; adding system-specific file 
handles would kill it for sure. 

I don't agree that this proposal pre- 
cludes multiple-file handling however, 
and let me explain why. I'll use Uniforih 
for my example, because that's what I 
know. 

In Uniforth there is a user variable 
called FCB. FCB points to the file handle 
(file control block, reference buffer, what- 
ever the OS in question uses) of the current 
open file. The value of FCB is changed by 
a set of words called: chana, Chanb, etc. 
To open two files simultaneously, for ex- 
ample, one would do the following: 

CHANA OPEN filel.fth 
CHANB OPEN f ile2 . f th 

A word that copies a line of text from 
one file to another would be something 
like this: 

: COPY-LINE 

( copy a line of text ) 
( from CHANA to CHANB ) 
CHANA pad 80 RDLINE 

( length - - ) 
CHANB pad swap WRLINE drop ; 

where I have used the Uniforth words 
RDLINE and WRLINE instead of my pro- 
posed words READ and WRITE. The code 
would be the same in either case. 

If the proposal were changed to in- 
clude file handles, I would anticipate 
changes like the following: 

OPEN ( - - fcb ) 

Open a file and return the file handle. 
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FUTURE 

announces 
Eight new products based on the NC4016 

Future Series products: 

CPU board (available 2nd quarter 1988) 

• NC4016 (5 MHz standard) 

• Stack and data RAM 

• Full 128Kbytes of paged main memory 

• Power fail detect 

• Automatic switching to on board battery backup at power fail 

• Psuedo-serial port - full compatibility with CM-FORTH and SC-FORTH 

• 16Kbytes of EPROM (SC-FORTH, SC-C and CM-FORTH available) 

Display/Debugger board (available 2nd quarter 1988) 

useful for testing and debugging custom hardware 

• Provides hexadecimal display of the data, address, and B-port 

• Indicates status of reset, interupt, WEB, WED, and X-port 

• Provides for free running and single step clocking 

• Provides the abihty to independently drive (write to) the data, address, and 

B-port directly with user data 

I/O board (available 2nd quarter 1988) 

for serial communication, interupt handling, event timing, time and date 
logging and saving system state parameters 

• Two RS232 serial ports 

• Eight level prioritized interupt controller. Each interupt line is individually 
maskable and resetable. Current pending interupt status is readable. 

• Real time clock with 2K of non-volatile RAM 

• Three 16-bit timer/counters 

Extended Memory board (available 3rd quarter 1988) 

• Paged memory — 64 Kbytes segments, up to eight segments 

Card Cage & Power Supply (available 3rd quarter 1988) 

• Rack mountable card cage with face plates for each slot 

• ±5 volts and ±12 volts supplied 

• 72 Pin backplane 

Disk Drive Controller board (available 3rd quarter 1988) 

• 3-1/2 inch floppy and SCSI controllers (for hard disks) 

Video board (available 4th quarter 1988) 

• Will drive Apple Macintosh n high resolution (640 x 480) monochrome 
monitor and PC compatible monochrome monitors 

A/D & D/A board (available 4th quarter 1988) 

• 12 bit, 1 MHz A/D & D/A converters 



Future, Inc. P.O. Box 10386 Blacksburg, VA 24062-0386 

(703) 552- 1347 

Apple is a registered trademark of ApjJc Computer, Inc. Macintodi is a trademark of Apple Corr^ter, Inc. 
SC-FORTH and SC-C arc products of Silicon Composers. 



CLOSE (fcb--) 

Close the file pointed to by the file handle. 

READ ( fcb adr lenl - - len2 ) 
As before except with file handle. 

WRITE ( fcb adr lenl - - len2 ) 
As before except with file handle. 

SEEK , FILEPOS , and WREOF would 
be changed similarly. Frankly, I don't see 
much difference in the ultimate use of these 
words. Returning the file handles means 
they must be saved somewhere in a vari- 
able. So the COPY-LINE above would 
become: 

COPY-LINE 

FCBl @ pad 80 READ 

FCB2 @ pad swap WRITE drop ; 

(In fact the definition of GHANA is 
something like: FCBl @ FCB ! andCHANB 
is FCB2 @ FCB ! for most, but not all 
operating system interfaces implemented.) 

So you see, it isn't difficult to handle 
multiple files using the proposed word set. 
Perhaps I should say that in the proposal, in 
order to make clear what I aheady thought 
would be understood implicitly. I keep 
forgetting that other systems handle things 
in very different ways. Do you think I 
should also propose some standard means 
of file switching? It should be as generic as 
possible, because the manipulation of file 
control blocks is different for every operat- 
ing system, while, in Uniforth at least, the 
ultimate top-level file operators like those 
above are uniform. 



To continue, I would like to say that I 
prefer "file-switching" words like CHANA 
and CHANB to explicit references to file 
handles, because the expHcit method is 
unnecessary and less self-documenting, 
and it follows the principle of "hiding data" 
ala Brodie's Thinking Forth. 

Leonard, thanks for pointing out the 
deficiencies in language in my proposal. I 
see that it must be more carefully written to 
avoid misinterpretation. When I say 
CLOSE will "close the file currently open," 
I should say "...close the file on the current 
file I/O channel" — after I define what a file 
I/O channel is of course. :-) 

The definition of READ should say that 
reading will stop "...when nl bytes of data 
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have been read, an end-of-file mark is en- 
countered, or in the case of a variable..." 

Finally, as I said above, my proposal 
isn't incompatible with "handles," it just 
assumed they are handled elsewhere (pun 
intended). 

Scott, about file creation: much more 
than size and name go into file creation, like 
access method, logical record length, 
blocking factor, data type (binary, charac- 
ter, executable, etc.), protection, and on and 
on. That's a pretty big can of worms. 

A request for file size is a good idea, and 
something I use a lot I'll add it to the list — 
Lee 

Category 10, Topic 23, Message 78 
Thu Mar 24, 1988 L.BROTZMAN 

Greg, 

Thanks for the tip on the proposal. I will 
try to amend the draft in light of the re- 
sponses above and get it in the mail ASAP. 
While we're talking about proposals, I 
asked Martin Tracy whether discussion on 
my DO LOOP proposal could be postponed 
until the November TC meeting at Goddard 
Space Flight Center, since I plan to attend 
that meeting and would then be available to 
explain and answer questions. He said I 
should ask you, so I'm asking. (Actually, if 
there is a move afoot to go back to Forth-79 
DO LOOPS, my proposal is obsolete, which 
is fine with me — I have no problems with 
the earlier DO structure). 

Sorry about sounding irate re BLOCK in 
this topic. I really have nothing against 
BLOCK in host file operations, it has its 
place. I just don't think that it is a panecea. 

My earlier postings about BLOCK in this 
topic have been (as far as I can recall with- 
out digging back into my log files) an effort 
to make it more compatible with the hosted 
environment, e.g. "undefined" block 
length, and releasing restrictions on buffer 
sizes. These are issues of little importance 
for standalone systems, but they could 
make life with BLOCK under an operating 
system a whole lot easier. 

I don't think I ever said block wasn't 
suitable to access a database, just that it isn ' t 
the only suitable way. I expressed this ex- 
plicitly in my last two messages, and I tried 
to be accommodating about saying that 
there are indeed times when block is the 
way to go — at least, that' s what I wanted to 
say. (Damn electronic communications... 
bad E-mail, bad!) 



Off the top of my head, the theoretical 
limit on throughput of a CD ROM drive is 
roughly 150 Kilobits/sec. I have not ana- 
lyzed our system as to actual throughput 
(we have to make the disk first!), but if you 
have friends at JPL, the guy to ask there is 
Mike Martin of the Planetary Data Systems 
Group. He has produced two CD ROMs of 
astronomical images and character-table 
data, and has written software to support it 
on IBM PC/AT/XT clones under MS- 
DOS . He told me that his throughput on the 
PC rivals that of an unloaded VAX reading 
from a hard disk, but VMS is such a dog 
that I won't venture to interpret that state- 
ment. 

The FITS files will be random access on 
the CD ROM. I would much prefer heavily 
indexed, flat text files but FITS has been 
foisted on me by NASA. Our first disk is 
simply a test of the CD ROM as storage and 
distribution medium, and FITS as a disk- 
based interchange format (currently, FITS 
is primarily for tapes, not disks, although 
several observatories have done some 
good work with disk-FITS already). The 
production schedule for this disk is too 
tight to allow more than minimal indexing 
for a few files (i.e., about 30 catalogs, 
totalling more than 50 files and 400 
Mbytes; final selection isn't set until mid- 
May). Subsequent disks, assuming that 
funding is continued, will include index 
files into the FITS formatted data, and 
more sophisticated data-base software. By 
that time, I hope to have the Forth software 
advanced enough to stave off the higher- 
ups that think it should be in C. 

You're right that the slow seek times 
are a real pain. Users are more than willing 
to put up with it, however, to get up to 600 
Mbytes of direct-access storage on their 
PCs, all in one place at a relatively low cost. 
Drives are running about $700, and most 
CD ROM application disks are about $ 1 00- 
200 — ours will be distributed for cost of 
media only, of course — $40-50 at most. 
There are now a few vendors of drives that 
claim to cut the seek time by quite a bit, but 
I haven't seen the spec sheets yet. — Lee 

P.S. Touche, JAX. A full-blown. Forth- 
based workstation environment couldn't 
end up any weirder or more esoteric than 
Unix, and that's pretty popular nowadays. 
Keep on trucking. 



Category 10, Topic 23, Message 79 
Thu Mar 24, 1988 S.W.SQUIRES [scott] 
Lee, 

I'd still prefer an explicit means of se- 
lecting a file. This would allow a variable 
(or better yet a TO-type variable) with a de- 
scriptive name for that particular program, 
(i.e. SOURCE, DESTINATION, AC- 
COUNTS, etc.) The potential problem with 
using the CHANA / CHANB is that the FCB 
is set until it is changed again. By looking 
at the source code for a program that did file 
access, you'd have to look back and deter- 
mine what set it the last time, if you didn't 
do it in the actual word doing the file access. 
Likewise, debugging could be confusing if 
FCB was set by a stray word. By passing the 
FCB (or file#) explicitly, the program can 
actually become more readable. Also, the 
usage is up to the programmer and he can 
use arrays or other structures if he desires. 
— Scott 

Category 10, Topic 23, Message 80 
Fri Mar 25, 1988 J.SHIFRIN 

Lee, I know I'll get confused trying to 
respond here and on the ECFB, but I still 
don' t think your files proposal is very solid. 
Nothing against UniForth, but I think the 
CHANA/CHANB approach is both a kludge 
and a bit bizarre. Also, I believe it falls apart 
in a multitasking enviroment. I don't care 
what's passed as a file identifier, but I think 
it should be a single stack item — an ad- 
dress or i.d. number which uniquely refers 
to something (FCB , HCB , DCB , filename) , 
implementation dependent, to describe the 
file being operated on 

[Sorry about the awkward prose — I 
hate the GEnie editor and didn ' t want to get 
into it for cleanup. Should've composed 
this offline!] 

Category 10, Topic 23, Message 81 
Sat Mar 26, 1988 G.BAILEYl 
[ATHENA] 

Lee, your proposal (known as TP88-038) is 
in the pile for consideration at the May TC 
meeting, and I will state your request to 
postpone its consideration as a motion to 
commit it to the group that is working on 
control structure and looping issues. We 
will probably convene that group at least 
once in Rochester and it is probable that this 
group will not have concrete recommenda- 
tions for some time. Unfortunately, it is 
difficult to indicate your willingness to 
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(McBrien's screens, from page 22.) 
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n 203 

OISFORTH Decompile Forth words to their component words ) 
DISFORTH ( DISFORTH cccc ) 

CR [COMPILE] ' DUP NFA ID. ' ( get PFA of cccc ) 

DUP NFA C@ 64 AND ( check the precidence bit ) 

IF ." ...is an IMMEDIATE word." 
THEN DUP CPA @ [ ' . CPA @ ] LITERAL = 

IF PRINT-DEF ( colon definition ) 

ELSE DUP CPA @ [ ' FENCE CFA @ ] LITERAL = 

IF ." ...is a USER variable. OFFSET = " @ . CR 
ELSE DUP CFA @ [ ' CFA @ ] LITERAL = 

IF ." ...is a CONSTANT. VALUE= " @ . CR 
ELSE DUP CFA @ [ ' USER CFA @ ] LITERAL = 
IF ." ...is a VARIABLE. CONTENTS' " @ 
ELSE ." ...is a CODE definition " CR 
DROP THEN THEN THEN THEN ; 
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OBRANCH 557B 

(.") IF... non zero print this line 
CR 

BRANCH 559F 
C . " ) ELSE. 

CR 

(.") THEN. 
CR 

; S ok 



if zero print this line 
regardless what print this line 



Screen 202 

1 ( PRINT-DEF 



More DISFORTHer words 



) 



PRINT-DEF ( pfa ) ( word is decompiled from that pfa ) 

BEGIN DUP @ TERMINATORS ELEMENT? 0= WHILE 
PRINT-WORD REPEAT PRINT-WORD DROP ; 



4 
5 

6 

7 ( AA is a test word for SEE to check the branches are resolved 

8 corectlv ) 
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I 1 
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1 6 
ok 



AA 



( n - 
CR 
I F 
ELSE 
THEN 



.) 

I F 
ELSE 
THEN 



non zero print this line" C R 
if zero print this line" C R 
regardless what print this line" C R 



(End of Letters screens.) 
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(Hoselton's screens, from page 18.) 


9 

t \ .SONS 


23 
\ .SCNS 


2 ! .ME (S n - ! 

3 CR SPACES l€ BODY) )Nfl!€ .ID ; 


DisDlay the name of the addressed OBJECT. 


5 HftSTES «tTOQD: (.SiNS) (S n ~ ) 

6 DIP .!€ e+ £ >CBJECT 

7 BEGIN # DUO WHIi.E 2DL'P 4 - (.SOi>S) REPEAT 
6 2DR0P i 

9 


DisDlay the naise of the addressed QBJcCT and, indented 

the names of all his descencent QBJECTs. This is a recursive 

routine. "LATE BINDING" is very useful here. 


18 HflSTER ICTHOD: .SONS t - ) 

U e (.SONS) ! 

12 

13 MASTER !€THOD! .ONE 

14 4 . re ; 
15 


Display the name of the current OBJECT and all nis 
descendents. 

Disoiay the name of the current OBJECT. 


10 

8 \ Testing t deuonstration 
i 

£ MASTER OBJECT: VEHICLE 
3 


24 

V Testing i demonstratiofi 


A "superclass" of vehicle types 


4 i^HICLE ICTHOD: tWHEELS B >SUPES » j 
5 

6 VEHICLE OBJECT: BOAT , 

7 VEHICLE OBJECT: CAR * , 

8 VEHICLE OBJECT: TRICYCLE 3 , 


ft METHOD for finding the rtuaber of wheels for a 

grandson of VEHICLE. 
An OBJECT whose imnediate descendants have ro wheels 
fin OBJECT whose immediate descendants have 4 wheels 
An OBJECT whose immediate descendents have 3 wheels 


9 

10 CAR (BJECT: GREEhi-RONSTER 

11 BOOT OBJECT: QUEEN-MARY 

12 \S 

13 DUEEN-NfiRY •WH£E;.S , 

14 GREEN-MONSTER iWHEELS . 
15 


a fasious car 

a famous boat ( Weil, really it's a ^ip ) 

How «any wneels coes the ffiJEEN-tlflRY have ? 

How many wheels does the GREEN-MONSTER have? 

.Mever say CAR IWHEELS . (#WHE£LS isn't written for that.) 


11 

\ Testirig & ce»ristration 
1 

2 MASTER OBJECT: ALTOKOBILE 

3 

4 


25 

\ Testing & demonstration 


A new example: AUTOMOBILE 

Note that this fiUTWDBILE is not a son of VEHICLE, 
ye' re on a new subject. 


5 

6 AUTOMOBILE METHOD: OBJECT: (S n - ) 

7 CREATE OBJECT) \ Build links 

8 0, \ 8) Odometer mileage 

3 0, \ 10) Oooneter Mileage @ last fillug 

10 , \ 12) gas in tank 

11 , J \ 14) miles-per gallon 
12 


AUTOMOBILE type OBJECT'S aren't cuite tne same as oromary 
OBJECT'S. They have sorse extra data appended. 
To define an AUTOMOBILE OBJECT, the Jiles-oer-gallon for 
that OBJECT must be on the stack. 


13 
14 
15 
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2 \ ^estir\^ & detnonstration 

£ flUTOICBlLE ICTHOD: DRIVE (S - ) 

3 14 > OBJECT a 1£ ) OBJECT 9 ♦ ( gas*rapg=ranDe ) MIN 
A DUP 6 ) OBJECT +' ( iricremerit odotiieter- ) 
5 DIP 14 ) OBJECT (? / NEGATE 12 ) OBJECT +' 

S .° Pa driving " . ." ailes " ; 
7 

8 !^TQI«BILE «THOD: "E.L-SflS (S -- ) 

9 le > OBJECT § CR 

li . " I HAVE " . . " 3ALL0NS lH MY TANK " ; 
11 

1£ ftUTOmSILE METHOD: FI.^-GflS (S n - ) 
13 12 ) OBJECT +: HE TELL-GflS ; 
14 
15 

13 

8 \ Testing t demoristration 
1 

2 7 flUT01<!QB!LE OBJECT: ftflCER 

3 23 fiUTa>ICBILE OBJECT: SLOW-POKE 
4 

5 SLOW-POKE CTHOD: TELL-GflS CR ." It's a secret^ " ; 

e 

7 

8 \S 
9 

18 13 RflCER FI:-L-GflS 

11 m RflCER DRI'vt 

12 RflCER TELL-GflS 

13 SLCSJ-POKE TELL-SfiS 
14 



26 

\ Testing t demoristration 

To drive our SUTO'^CBILE ft itiles, we first check our rari^e, 
( gas times i«iles-pei"-|aliori ) to see t\Q*t far we can gc. 
Then m ircmsent our odometer reading, decrease our fuel 
and report just hoN far we drove. 

Report the fuel in the tank. 



ftdd fuel to the tank. 

In a raore complicated exawple, we lioht check the cas tank 
capacity, reduce the driver's casn, etc. 

27 

\ Testing t demonstration 

High performance, seven isi les-per-gallon. 

Low performance, twenty-three ai les-per-gal Ion. 

Some privacy for SLOW-POKE 

This shows that different objects can use the same MESSAGE 
name to produce different results. 

Put some gas iri the tank. 
Drive for a while. 
Report gas remaining. 



Evaluation 

I searched for an object-Forth support 
routine that met these objectives, but I 
didn't find any that really suited me. Neon 
provides some fine object tools, but it has 
changed so much that it isn't Forth any 
more. Vocabulary-based implementations 
of object Forth can be slow, and none that 
1 examined support late binding. So, I wrote 
my own object Forth. 

Rather ihan supporting an explicit class 
construction, this routine supports inheri- 
tance by causing each object to be the "son" 
of some other object. "Brother" and 



"cousin" objects can inherit data, data 
structure, and methods from the common 
"ancestors." 

There don ' t seem to be any bugs left, but 
there is a "feature" I don't like: it is easy to 
misuse a method. A method might be de- 
signed only to be inherited. It might not 
work at all with the original object, but it is 
still possible to make that request Another 
warning: don't use a name for a message if 
that name has already been used for some- 
thing else. There is very little error check- 
ing; when you ask for a mistake, you usu- 
ally get one. 



Summary 

Here is a fast, late binding, and free 
object-Forth support routine. It runs un- 
der Laxen and Perry's public-domain 
F83. Now you possess Forth, the world's 
most powerful programming language, 
and support for one of the world's most 
powerful conceptual tools: object-ori- 
ented programming. 

Rick Hoselton is a professional Forth 
programmer with General Ir^ormation 
Technologies, Inc. His work with Forth 
spans the last six of his seventeen years 
spent as a full-time computer profes- 
sional. 
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YES, THERE IS A BETTER WAY 
A FORTH THAT ACTUALLY 
DELIVERS ON THE PROMISE 

"Vforth 

POWER 

HS/FORTH's compilation and execution speeds are 
unsurpassed. Compiling at 20,000 lines per minute, it 
compiles faster ttian many systems link. For real jobs 
execution speed is unsurpassed as well. Even non- 
optimized programs run as fast as ones produced by 
most C compilers. Forth systems designed to fool 
bencfimarks are sligfitly faster on nearly empty do 
loops, but bog down when tfie colon nesting level ap- 
proaches anything useful, and have much greater 
memory overhead for each definition. Our optimizer 
gives assembler language performance even for 
deeply nested definitions containing complex data and 
control structures. 

HS/FORTH provides the best architecture, so good that 
another major vendor "cloned" (rather poorly) many of 
its features. Our Forth uses all available memory for 
both programs and data with almost no execution time 
penalty, and very little memory overhead. None at all for 
programs smaller than 200kB. And you can resize seg- 
ments anytime, without a system regen. With the 
GigaForth option, your programs transparently enter 
native mode and expand into 1 6 Meg extended memory 
oragigabyte of virtual, and run almost as fast as in real 
mode. 

Benefits beyond speed and program size include word 
redefinition at any time and vocabulary structures that 
can be changed at will, for instance from simple to 
hashed, or from 79 Standard to Forth 83. You can be- 
head word names and reclaim space at any time. This 
includes automatic removal of a colon definition's local 
variables. 

Colon definitions can execute inside machine code 
primitives, great for interrupt & exception handlers. 
Multi-cfa words are easily implemented. And code 
words become incredibly powerful, with multiple entry 
points not requiring jumps over word fragments. One of 
many reasons our system is much more compact than 
its immense dictionary (1 600 words) would imply. 

INCREDIBLE FLEXIBILITY 

The Rosetta Stone Dynamic Linker opens the world of 
utility libraries. Link to resident routines or link & remove 
routines interactively. HS/FORTH preserves relocata- 
bility of loaded libraries. Link to BTRIEVE METAWIN- 
DOWS HALO HOOPS ad infinitum. Our call and data 
structure words provide easy linkage. 

HS/FORTH runs both 79 Standard and Forth 83 pro- 
grams, and has extensions covering vocabulary search 
order and the complete Forth 83 test suite. It loads and 
runs all FIG Libraries, the main difference being tney 
load and run faster, and you can develop larger applica- 
tions than with any other system. We like source code in 
text files, but support both file and sector mapped Forth 
block interfaces. Both line and block file loading can be 
nested to any depth and includes automatic path 
search. 



FUNCTIONALITY 

More important than how fast a system executes, is 
whether it can do the job at all. Can it work with your 
computer. Can it work with your other tools. Can it trans- 
form your data into answers, A language should be 
complete on the first two, and minimize the unavoidable 
effort required for the last, 

HS/FORTH opens your computer like no other lan- 
guage. You can execute function calls, DOS com- 
mands, other programs interactively, from definitions, 
or even from files being loaded. DOS and BIOS function 
calls are well documented HS;FORTH words, we don't 
settle for giving you an INTCALLand saying "have at it". 
We also include both fatal and informative DOS error 
handlers, installed by executing FATAL or INFORM. 

HS/FORTH supports character or blocked, sequential 
or random I/O. The character stream can be received 
from sent to console, file, memory, printer or com port. 
We include a communications plus upload and down- 
load utility, and foreground/background music. Display 
output through BIOS for compatibility or memory 
mapped for speed. 

Our formatting and parsing words are without equal. In- 
teger, double, quad, financial, scaled, time, date, float- 
ing or exponential, all our output words have string 
formatting counterparts for building records. We also 
provide words to parse all data types with your choice of 
field definition. HS/FORTH parses files from any lan- 
guage. Other words treat files like memory, nn@H and 
nn!H read or write from/to a handle (file or device) as 
fast as possible. For advanced file support, HS/FORTH 
easily links to BTRIEVE, etc, 

HS/FORTH supports text/graphic windows for MONO 
thru VGA, Graphic drawings (line rectangle ellipse) can 
be absolute or scaled to current window size and 
clipped, and work with our penplot routines. While great 
for plotting and line drawing, it doesn't approach the ca- 
pabilities of Metawindows (tm Metagraphics). We use 
our Rosetta Stone Dynamic Linker to interface to Meta- 
windows. HS/FORTH with MetaWindows makes an un- 
beatable graphics system. Or Rosetta to your own 
preferred graphics driver, 

HS/FORTH provides hardware/software floating point, 
including trig and transcendentals. Hardware fp covers 
full range trig, log, exponential functions plus complex 
and hyperbolic counterparts, and all stack and compari- 
son ops. HS/FORTH supports all 8087 data types and 
works in RADIANS or DEGREES mode. No coproces- 
sor? No problem. Operators (mostly fast machine code) 
and parse/format words cover numbers through 1 8 dig- 
its. Software fp eliminates conversion round off error 
and minimizes conversion time. 

Single element through 4D arrays for all data types in- 
cluding complex use multiple cfa's to improve both per- 
formance and compactness. Z = (X-Y) / (X + Y) would 
be coded; X Y - X Y -t- / IS Z (16 bytes) instead of: X &• 
Y(a}-X(a)Y(a< + /Z!(26 bytes) Arrays can ignore 64k 
boundaries. Words use SYNONYMS for data type inde- 
pendence. HS/FORTH can even prompt the user for 
retry on erroneous numeric input. 

The HS/FORTH machine coded string library with up to 
3D arrays is without equal. Segment spanning dynamic 
string support includes insert, delete, add, find, replace, 
exchange, save and restore string storage. 

Our minimal overhead round robin and time slice multi- 
taskers require a word that exits cleanly at the end of 
subtask execution. The cooperative round robin multi- 
tasker provides individual user stack segments as well 
as user tables. Control passes to the next task/user 
whenever desired. 



APPLICATION CREATION TECHNIQUES 

HS/FORTH assembles to any segment to create stand 
alone programs of any size. The optimizer can use HS/ 
FORTH as a macro library, or complex macros can be 
built as colon words. Full forward and reverse labeled 
branches and calls complement structured flow control. 
Complete syntax checking protects you. Assembler 
programming has never been so easy. 

The Metacompiler produces threaded systems from a 
few hundred bytes, or Forth kernels from 2k bytes. With 
it, you can create any threading scheme or segmenta- 
tion architecture to run on disk or ROM, 

You can turnkey or seal HS/FORTH for distribution, with 
no royalties for turnkeyed systems. Or convert for ROM 
in saved, sealed or turnkeyed form, 

HS/FORTH includes three editors, or you can quickly 
shell to your favorite program editor. The resident full 
window editor lets you reuse former command lines and 
save to or restore from a file. It is both an indispensable 
development aid and a great user interface. The macro 
editor provides reuseable functions, cut, paste, file 
merge and extract, session log, and RECOMPILE. Our 
full screen Forth editor edits file or sector mapped 
blocks. 

Debug tools include memory/stack dump, memory 
map, decompile, single step trace, and prompt options. 
Trace scope can be limited by depth or address. 

HS/FORTH lacks a "modular" compilation environ- 
ment. One motivation toward modular compilation is 
that, with conventional compilers, recompiling an entire 
application to change one subroutine is unbearably 
slow. HS/FORTH compiles at 20,000 lines per minute, 
faster than many languages link — let alone compile! 
The second motivation is linking to other languages. 
HS/FORTH links to foreign subroutines dynamically. 
HS/FORTH doesn't need the extra layer of files, or the 
programs needed to manage them. With HS/FORTH 
you have source code and the executable file. Period. 
"Development environments " are cute, and necessary 
for unnecessahly complicated languages. Simplicity is 
so much better. 

HS/FORTH Programming Systems 

Lower levels include all functions not named at a higher 



level. Some functions available separately. 
Documentation & Working Demo 

(3 books, 1 000 -I- pages, 6 lbs) $ 95, 

Student $145, 

Personal optimizer, scaled & quad integer $245. 

Professional 80x87, assembler, turnkey, $395. 



dynamic strings, multitasker 
RSDL linker, 
physical screens 
Production ROM, Metacompiler, Metawindows 

$495. 



Level upgrade, pnce difference plus $ 25. 

OBJ modules $495. 
Rosetta Stone Dynamic Linker $ 95. 

Metawindows by Metagraphics (includes RSDL) 

$145. 

Hardware Floating Point & Complex $ 95. 

Quad integer, software floating point $ 45. 

Time slice and round robin multitaskers $ 75. 



GigaForth (80286/386 Native mode extension) $295. 

HARVARD 
SOFTWORKS 

PO BOX 69 
SPRINGBORO, OH 45066 
(513) 748-0390 
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FIG 
CHAPTERS 



The FIG Chapters listed be- 
low are cuirently registered as 
active with regular meetings. If 
your Chapter listing is missing or 
incorrect, please contact Kent 
Safford at the the FIG office's 
Chapter Desk. This listing will 
be upxlated in each issue of Forth 
Dimensions. If you would Uke to 
begin a FIG Chapter in your area, 
write to the Chapter Desk for a 
"Chapter Kit and Application." 
Forth Interest Group, P.O. 
Box 8231, San Jose, California 
95155 

U.S.A. 

• ALABAMA 
Huntsville Chapter 

Tom Konantz (205) 881-6483 

• ALASKA 
Kodiak Area Chapter 

Horace Simmons (907) 486- 
5049 

• ARIZONA 
Phoenix Chapter 
4thThurs., 7:30 p.m. 
Dennis L. Wilson (602) 956- 
7578 

• ARKANSAS 

Central Arkansas Chapter 

Little Rock 

2nd Sat., 2 p.m. & 

4th Wed., 7 p.m. 

Jungkind Photo, 12th & Main 

Gary Smith (501)227-7817 

• CALIFORNM 
Los Angeles Chapter 
4th Sat., 10 a.m. 
Hawthorne Public Library 
12700 S.GreviUea Ave. 
Phillip Wasson (213) 649-1428 



North Bay Chapter 

2nd Sat., 10 a.m. Forth, AI 
12 Noon Tutorial, 1 p.m. Forth 
South Berkeley Public Library 
George Shaw (415) 276-5953 

Orange County Chapter 

4th Wed., 7 p.m. 

FuUerton Savings 

Huntington Beach 

Noshir Jesung (714) 842-3032 

San Diego Chapter 

Thursdays, 12 Noon 
Guy Kelly (619) 454-1307 

Sacramento Chapter 
4th Wed., 7 p.m. 
1798-59th St., Room A 
Tom Ghormley (916) 444-7775 

Silicon Valley Chapter 

4th Sat., 10 a.m. 

H-P Cupertino 

Bob Ban- (408) 435-1616 

Stockton Chapter 

Doug Dillon (209) 931-2448 

• COLORADO 
Denver Chapter 
1st Mon., 7 p.m. 

Clifford King (303) 693-3413 

• CONNECTICUT 
Central Connecticut Chapter 

Charles Rrajewski (203) 344- 
9996 

• FLORIDA 

Southeast Florida Chapter 

Coconut Grove Area 

John Forsberg (305) 252-0108 

Tampa Bay Chapter 

1st Wed., 7:30 p.m. 

Terry McNay (813) 725-1245 



• GEORGIA 
Atlanta Chapter 

3rd Tues., 6:30 p.m. 
Western Sizzlen, Doraville 
Nick Hennenfent (404) 393-3010 

• ILLINOIS 

Cache Forth Chapter 
Oak Park 

Clyde W. PhilUps, Jr. (312) 386- 
3147 

Central Illinois Chapter 

Urbana 

Sidney Bowhill (217) 333^150 

• INDIANA 

Fort Wayne Chapter 

2nd Tues., 7 p.m. 

I/P Univ. Campus, B71 Neff Hall 

Blair MacDermid (219) 749- 

2042 

•IOWA 

Central Iowa FIG Chapter 

1st Tues., 7:30 p.m. 

Iowa State Univ., 214 Comp. Sci. 

Rodrick Eldridge (515) 294-5659 

Falrfleld FIG Chapter 

4th Day, 8:15 p.m. 

Gurdy Leete (515) 472-7077 

• MASSACHUSETTS 
Boston Chapter 

3rd Wed., 7 p.m. 
Honeywell 

300 Concord, BiUerica 

Gary Chanson (617) 527-7206 

• MICHIGAN 
Detroit/Ann Arbor Area 

4th Thurs. 

Tom Chrapkiewicz (313) 322- 
7862 



• MINNESOTA 
MNFIG Chapter 

Minneapolis 

Even Month, 1st Mon., 7:30 p.m. 
Odd Month, 1st Sat., 9:30 a.m. 
Vincent Hall, Univ. of MN 
Fred Olson (612) 588-9532 

• MISSOURI 
Kansas City Chapter 
4th Tues., 7 p.m. 
Midwest Research Institute 
MAG Conference Center 
Linus Orth (913) 236-9189 

St. Louis Chapter 

1st Tues., 7 p.m. 
Thomhill Branch Library 
Robert Washam 
91 Weis Drive 
EUisviUe, MO 63011 

• NEW JERSEY 
New Jersey Chapter 
Rutgers Univ., Piscataway 
Nicholas Lordi (201) 338-9363 

• NEW MEXICO 
Albuquerque Chapter 
1st Thurs., 7:30 p.m. 
Physics & Astronomy Bldg. 
Univ. of New Mexico 

Jon Bryan (505) 298-3292 

. NEW YORK 
FIG, New York 
2nd Wed., 7:45 p.m. 
Manhattan 

Ron Martinez (212) 866-1157 

Rochester Chapter 

Monroe Comm. College 

Bldg. 7, Rm. 102 

Frank Lanzafame (716) 462- 

3398 
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. NORTH CAROLINA 
Raleigh Chapter 

Frank Bridges (919) 552-1357 

• OHIO 

Cleveland Chapter 

4th Tues., 7 p.m. 

Chagrin Falls Library 

Gary Bergstrom (216) 247-2492 

Dayton Chapter 

2nd Tues. & 4th Wed.. 6:30 p.m. 
CFC. 11 W. Monument Ave. 
#612 

Gary Ganger (513) 849-1483 

• OKLAHOMA 

Central Oklahoma Chapter 

3rd Wed., 7:30 p.m. 

Health Tech. Bldg., OSU Tech. 

Larry Somers 

2410 N.W. 49th 

Oklahoma City, OK 73112 

. OREGON 

Willamette Valley Chapter 
4th Tues., 7 p.m. 
Linn-Benton Comm. College 
Pann McCuaig (503) 752-51 13 

• TENNESSEE 

East Tennessee Chapter 

Oak Ridge 

2nd Tues., 7:30 p.m. 

Sci. Appl. Int'l. Corp., 8th Fl 

800 Oak Ridge Turnpike 

Richard Secrist (615) 483-7242 

. TEXAS 
Austin Chapter 

Matt Lawrence 
PO Box 180409 
Austin, TX 78718 

Houston Chapter 

3rd Mon., 7:45 p.m. 

Intro Class 6:30 p.m. 

Univ. at St. Thomas 

Russell Harris (713) 461-1618 

•UT.\H 

North Orem Chapter 

Ron Tanner 
748 N. 1340 W. 
Orem, UT 84057 

• VERMONT 
Vermont Chapter 

Vergennes 
3rd Mon., 7:30 p.m. 
Vergennes Union High School 
RM 210, Monkton Rd. 
Hal Clark (802) 453-4442 



• VIRGINIA 

First Forth of Hampton Roads 

William Edmonds (804) 898- 
4099 

Richmond Forth Group 

2nd Wed., 7 p.m. 

154 Business School 

Univ. of Richmond 

Donald A. Full (804) 739-3623 

• WISCONSIN 

Lake Superior Chapter 

2nd Fri., 7:30 p.m. 

1219 N. 21st St., Superior 

Allen Anway (715) 394-4061 

MAD Apple Chapter 
Bill Horton 
502 Atlas Ave. 
Madison, WI 53714 

INTERNATIONAL 

• AUSTRALIA 
Melbourne Chapter 
1st Fri., 8 p.m. 
Lance Collins 

65 Martin Road 

Glen Iris, Victoria 3146 

03/29-2600 

Sydney Chapter 
2nd Fri., 7 p.m. 

John Goodsell Bldg., RM LG19 

Univ. of New South Wales 

Peter Tregeagle 

10 Binda Rd., Yowie Bay 2228 

02/524-7490 

• BELGIUM 
Belgium Chapter 
4th Wed., 8 p.m. 
Luk Van Loock 
Lariksdreff 20 
2120 Schoten 
03/658-6343 

Southern Belgium Chapter 

Jean-Marc Bertinchamps 
Rue N. Mormom, 2 
B-6290 Nalinnes 
071/213858 

• CANADA 

Northern Alberta Chapter 

4th Sat., 1 p.m. 

N. Alta. Inst, of Tech. 

Tony Van Muyden (403) 962- 

2203 

Southern Ontario Chapter 

(Quarterly, 1st Sat., Mar., Jun., 

Sep., Dec, 2 p.m. 

Genl. Sci. Bldg., RM212 

McMaster University 

Dr. N. Solntseff (416) 525-9140 

x3443 



Toronto Chapter 

John Clark Smith 

PO Box 230, Station H 

Toronto, ON M4C 5J2 

Vancouver Chapter 

Don Vanderweele (604) 941- 
4073 

• ENGLAND 

Forth Interest Group-UK 

London 

1 st Thurs., 7 p.m. 

Polytechnic of South Batik 

RM408 

Borough Rd. 

D.J. Neale 

58 Woodland Way 

Morden, Surry SM4 4DS 

• FRANCE 

French Language Chapter 

Jean-Daniel Dodin 
77 Rue du Cagire 
31 100 Toulouse 
(16-61)44.03.06 

• HOLLAND 
Holland Chapter 

Adriaan van Roosmalen 
Heusden Houtsestraat 134 
4817 We Breda 
31 76 713104 

•ITALY 
FIG Italia 

Marco Tausel 

Via Gerolamo Fomi 48 

20161 Milano 

02/435249 

• JAPAN 
Japan Chapter 

Toshi Inoue 

Dejd. of Mineral Dev. Eng. 
University of Tokyo 
7-3-1 Hongo, Bunkyo 113 
812-2111 x7073 

• NORWAY 
Bergen Chapter 

Kjell Birger Faeraas, 47-518- 
7784 

• REPUBLIC OF CHINA 
(R.O.C.) 

Ching-Tang Tzeng 
PO Box 28 

Lung-Tan, Taiwan 325 

• SWEDEN 
SweFIG 
Per Aim 
46/8-929631 



• SWITZERLAND 
Swiss Chapter 
Max Hugelshofer 

ERNI & Co., Elekiro-Industrie 
Stationsstrasse 
8306 Bruttisellen 
01/833-3333 

SPECIAL GROUPS 

• NC4000 Users Group 

John Carpenter (415) 960-1256 
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NOW FOR IBM PC, XT, AT. PS2 
AND TRS-80 MODELS 1 , 3, 4, 4P 

The Gltted 
Computer 

1. Buy MMSFORTH before year's end, 
to let your computer work harder and 
faster. 

2. Then MMS will reward it (and you) 
with the MMSFORTH GAMES DISK, 

a $39.95 value which we'll add on at 

no additional charge! 
MMSFORTH is the unusually smooth 
and complete Fortti system with the 
great support. Many programmers report 
lour to ten timet greater productivity 
with this outstanding system, and MMS 
provides advanced application* pro- 
grams in Forth for use by beginners and 
for custom modifications. Unlike many 
Forths on the market, MMSFORTH gives 
you a rich set of the instructions, editing 
and debugging tools that professional 
programmers want. The licensed user 
gets continuing, free phone tips and a 
MMSFORTH Newsletter is available. 
The MMSFORTH GAMES DISK includes 
arcade games (BREAKFORTH, CRASH- 
FORTH and, for TRS-80, FREEWAY), 
board games (OTHELLO and TIC-TAC- 
FORTH), and a top-notch CRYPTO- 
QUOTE HELPER with a data file of 
coded messages and the ability to en- 
code your own. All of these come with 
Forth source code, for a valuable and 
enjoyable demonstration of Forth pro- 
gramming techniques. 
Hurry, and the GAMES DISK will be our 
free gift to you. Our brochure is free, 
too. and our knowledgeable staff is 
ready to answer your questions. Write. 
Better yet, call 617/653-6136. 




FOKTH 



and a free gift! 



GREAT FORTH: 

MMSFORTH V2.4 $179.95* 

The one you've read about in FORTH; A 
TEXT & REFERENCE. Available for IBM 
PC/XT/AT/PS2 etc., and TRS-80 M.I, 3 
and 4 

GREAT MMSFORTH OPTIONS: 

FORTHWRITE $99.95' 

FORTHCOM 49.95 

DATAHANDLER 59.95 

DATAHANDLER-PLUS* 99.95 

EXPERT-2 69.95 

UTILITIES 49,95 

'Single-computer, single-user prices; cor- 
porate site licenses from $1,000 additional. 
3%" format, add $5/disk; Tandy 1000. add 
$20. Add S/H, plus 5% tax on Mass. orders. 
DH+ not avail, for TRS-BOs. 
GREAT FORTH SUPPORT: 
Free user tips, MMSFORTH Newsletter, 
consulting on hardware selection, staff 
training, and programming assignments 
large or small. 
GREAT FORTH BOOKS: 

FORTH: A TEXT & REF. $21.95* 

THINKING FORTH 16.95 

Many others in stock. 

MILLER MICROCOMPUTER SERVICES 
61 Lake Shore Road, Natick, MA 01760 
(617/653-6136, 9 am - 9 pm) 



(Data Structures, from page 14.) 

tier of operations is a virtue of Forth. Char- 
les Moore preserved a great deal of flexibil- 
ity by manipulating values in steps: an 
object in memory is fetched to the stack, 
converted to a cell-length object (or mul- 
tiples thereof), processed by whatever 
postfix operators are available to the 
object's supertype (you might say there are 
only two types at this point: doubles and 
cells), and then stored with the correct 
operators (back to three data types). 

Conclusion 

Other languages don't support the crea- 
tion of new data types; they leave you with 
a small vocabulary of basic types and meth- 
ods from which to build compound types 
such as records. The basic type vocabulary 
also tends to be a minimal one. Each of the 
few basic types available is usually quite 
different from the others. Contrast this with 
Forth, where you can create a dozen string 
data types if you need them. And within 
twelve different applications, you may find 
yourself needing them. 

Forth doesn't presume to have discov- 
ered all the basic data objects or types 
needed to solve your problems. With its 
limited but extensible base. Forth provides 
the opportunity to create just the data type 
or data object you need. 

Copyright © 1988 byMikeElola. All rights 
reserved. 



Mike Elola is a published Forth pro- 
grammer and a full-time writer at Apple 
Computer. Over the years, Mike feels. 
Forth has tricked him into believing that 
he is a computer scientist. 



(Editorial, from page 3.) 

tors of the Forth Interest Group. Under his 
leadership, the 1988 Forth National Con- 
vention ('The 1988 Real-Time Program- 
ming Convention," featuring banquet 
speaker Jef Raskin and keynote speaker 
Ray Duncan) will be held November 18 - 
19 in Anaheim, California (across from 
Disneyland). Los Angeles and Orange 
County have local FIG members with the 
expertise, professionalism, and energy to 
lend to an exciting event. We are looking 
forward to traveling there, and hope to see 
you there. Bring along your computer and 
favorite language, too: the black-belt pro- 
grammers contest offers a SIOOO prize — 
write to RG for a copy of the rules. 

— Marlin Ouverson 

Editor 



(GEnie.from page 31.) 

accept the Forth-79 definition in our audit 
trail, and unless someone generates a pro- 
posal to that effect there is no way it can 
even be considered. If you consider the 
Forth-79 loop behavior to be equally desir- 
able, there is absolutely nothing wrong 
with submitting a separate proposal to that 
effect. There are plentiful cases where a 
submitter finds two mutually exclusive 
changes equally acceptable, and in such a 
case two proposals are easier to work with 
than would be a single proposal outlining 
two possibilities. Cheers —Greg. 
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Investigate career opportunities with Digalog 



Experience: 

• > 5 yrs programming, 3 yrs Forth 

• Realtime instrumentation & Control 

• Linear algebra, Z transforms, 
state space 

• Strong hardware background 



Interests: 

• Software Product design 

• Applications language development 

• Automotive or aerospace laboratories 

• Relocating to Ventura, California 



Send resume to: 



Digalog Corporation • PO Box 3315 • Ventura, CA 93006-3315 • 805/644-9928 
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SIOOO EEWfiRD 

for the World's Fastest Programmer. 



Be the first to put our mystery gizmo through its paces and 
win $1000! Use any computer, any software. The showdown is 
at the Real-Time Programming Convention, Nov 18-1 9th, 
Anaheim, Calif. For complete rules, write: 
Programming Contest, Forth Interest Group, PO Box 8231, 
San Jose, CA 95155. 



Forth Interest Group 

P.O.Box 8231 

San Jose, CA 95155 



Second Class 
Postage Paid at 
San Jose, CA 



